- From: Bill Roberts <bill@swirrl.com>
- Date: Sat, 11 Mar 2017 10:21:48 +0000
- To: Jeremy Tandy <jeremy.tandy@gmail.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>
- Message-ID: <CAMTVsukECNGBHEOJm+HujtBkg4c0ny=+ERpPrtcoVnxD3HppMA@mail.gmail.com>
interesting - though I think that's going to be too detailed to get into in the BP - unless you want BP10 to be 20 pages long! On 11 March 2017 at 10:05, Jeremy Tandy <jeremy.tandy@gmail.com> wrote: > 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:22:23 UTC