- From: Erik Wilde <erik.wilde@dret.net>
- Date: Tue, 16 Feb 2016 10:44:37 +0100
- To: Di Donato Pasquale swisstopo <Pasquale.DiDonato@swisstopo.ch>, "public-sdw-comments@w3.org" <public-sdw-comments@w3.org>
- Cc: Sean Gillies <sean.gillies@gmail.com>
hello pasquale. On 2016-02-15 16:13 , Di Donato Pasquale swisstopo wrote: > Here at swisstopo we are interested in GeoJSON-LD, since our SDI is > entirely based on a REST API. Then the question about the “geometry” > object in GeoJSON. please keep in mind that there is no such thing as *the* "GeoJSON-LD". the name has been used by various communities and generically refers to some way how to use JSON-LD to map GeoJSON to RDF. how to best do this is not trivial, in particular because GeoJSON relies so heavily on sequences in its data model, which do not work well in RDF. if and how there will be *a* GeoJSON-LD remains to be seen. in the IETF GeoJSON WG (which i am co-chairing) we have had some discussions around the idea, but for the upcoming RFC work we have decided that we are focusing on GeoJSON only. GeoJSON-LD is out of scope. > As far as I can understand the specifications, when I model a feature > object I have to use the geometry object, with the restriction to only > one geometry object. https://tools.ietf.org/html/draft-ietf-geojson-00#section-2 says: "GeoJSON always consists of a single object. This object (referred to as the GeoJSON object below) represents a geometry, feature, or collection of features." so yes, GeoJSON by definition is a single JSON object. but you can have a "Feature Collection" which is an array of Feature objects: https://tools.ietf.org/html/draft-ietf-geojson-00#section-2.3 there also is a "Geometry Collection" which allows you to represent an array of geometry objects: https://tools.ietf.org/html/draft-ietf-geojson-00#section-2.1.8 > Is that right? Have you considered that sometimes geospatial features > may have more than one geometry property? For example a city can be > represented as a point or as a polygon depending on the scale of > visualization. the point of GeoJSON is not to represent the full complexity of spatial models, for example different spatial representations on different zoom levels. overloading GeoJSON this much very quickly will lead you to GeoJSON that only you can meaningfully use, and which others will interpret in different and unpredictable ways. it makes more sense to think of GeoJSON as something that allows you to represent geo features in a given context, such as a city on a certain zoom level. i am cc'ing sean gillies who is one of the original authors of GeoJSON to make sure that i am not saying something that i shouldn't say. but afaict, GeoJSON is intentionally modest and tries hard not to be the spatial übermodel that can do it all. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret |
Received on Tuesday, 16 February 2016 09:45:09 UTC