W3C home > Mailing lists > Public > public-sdw-wg@w3.org > March 2017

Re: Inclusion of non-geometric ways to describe location (e.g. address and geocode) in BP10?

From: Jeremy Tandy <jeremy.tandy@gmail.com>
Date: Sat, 11 Mar 2017 10:05:02 +0000
Message-ID: <CADtUq_3G+N4_hXyM73wRHJ+uOoBOKT9mKbAEqtriOx5=2-E+Fw@mail.gmail.com>
To: Bill Roberts <bill@swirrl.com>
Cc: Andrea Perego <andrea.perego@ec.europa.eu>, Linda van den Brink <l.vandenbrink@geonovum.nl>, SDW WG Public List <public-sdw-wg@w3.org>
Hi Bill - just one more thing (again!) ...

I was talking to a colleague of mine earlier this week about how he's
publishing spatial data on the Web; making use of GeoJSON, elastic-search,
open layers etc. All good "modern" webby stuff. One of the bits of advice
he gave was:

"keep your data structures FLAT (avoid nesting/embedded objects; as per OGC
GML Simple Features Profile) - this makes it easier for users to work with
in existing tools (e.g. ElasticSearch)"

He refers to the structures in GeoJSON [1] "properties" object (see 3.2
Feature Object [2]) and (I would assume) any "foreign members" [3]. This
makes it easier to import the GeoJSON documents into elastic search etc. (I
think that's what he said)

The OGC's GML Simple Features Profile [4] defines three levels of
compliance: SF-0, SF-1 and SF-2 - each of which become progressively less
restrictive profiles from 0 to 2. Above 2 you're using everything that GML
has; kitchen sink and all! I wonder if these notions of profiling for
interoperability might be a useful inclusion in BP10? section "2.1
Introduction" provides a good starting point (but then I suppose that's the
point).

Jeremy

[1]: https://tools.ietf.org/html/rfc7946
[2]: https://tools.ietf.org/html/rfc7946#section-3.2
[3]: https://tools.ietf.org/html/rfc7946#section-6.1
[4]: http://portal.opengeospatial.org/files/?artifact_id=42729

On Sat, 11 Mar 2017 at 09:29 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:

> Thanks Bill.
>
> On Sat, 11 Mar 2017 at 09:18 Bill Roberts <bill@swirrl.com> wrote:
>
> Hi Jeremy
>
> Good idea - I think it would be good to include something about addresses
> and geocodes as a way of encoding location.  I'll try to incorporate
> something on that.
>
>
>
> On 11 March 2017 at 09:08, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
> Hi Bill.
>
>
> Given that Andrea is talking about _geometries_ in BP8, we seem to have a
> gap with regard to _other_ mechanisms to describe location; e.g. addresses
> and geocodes (postal codes etc., geohashes [1] and, I think worth
> mentioning explicitly, W3W [2]).
>
>
> In you discussion of “how to encode spatial data” I think it is worth
> calling these mechanisms out specifically, and referring to Andrea’s work
> on geometries in BP8.
>
>
> Given Andrea's involvement with the ISA Programme Location Core Vocabulary
> [3] (which defines locn:Address), he may have some useful contributions
> here too.
>
>
> Addresses are mentioned in the following use cases:
>
>    - 4.5 Harvesting of Local Search Content
>    - 4.9 Enabling publication, discovery and analysis of spatiotemporal
>    data in the humanities
>    - 4.13 Publication of air quality data aggregations
>
>
> Strangely, we don’t have any requirements that mention addresses.
>
>
> I’m also reminded of the Discrete Global Grid System (DGGS) standard being
> prepared by OGC [4] which will … For example, HEALPix (“Hierarchical Equal
> Area isoLatitude Pixelization”) grids, an indexing system used for DGGS,
> are useful for EO data because each cell is uniquely identified and has
> equal-area (at that level in the grid) so that you don’t need to re-sample
> when comparing cell properties; the value of each cell is directly
> comparable. DGGS and HEALPix are (were?) referenced in the EO-QB work of
> our group.
>
>
> That said, I don’t think the DGGS is formally approved as a standard, so
> it may only warrant a note - or no mention at all. I doubt it meets our
> criteria for “best practice in the wild”. It also looks a little complex
> from my quick scan of the OGC doc.
>
>
> There are also clearly a large number of other coding systems for
> geographical and administrative areas & places. I’ll try to cover referring
> to these types of things in BP14 concerning linking.
>
>
> Given the short amount of time available before our intended “freeze” (on
> Wed 15-Mar) of the BP doc for next WD release, I’d be content to push these
> changes into the work plan for the next sprint.
>
>
> Jeremy
>
>
>
> [1]: https://en.wikipedia.org/wiki/Geohash
>
> [2]: http://what3words.com
>
> [3]: https://www.w3.org/ns/locn#
>
> [4]: public draft: OGC #15-104r3
> https://portal.opengeospatial.org/files/66643
>
>
>
>
>
Received on Saturday, 11 March 2017 10:05:46 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 11 March 2017 10:05:47 UTC