Re: Quick question after the Spatial Data on the Web Conference in Amsterdam

An interesting point, that was I think part of an ongoing more
philosophical point we have discussed for the last few months.  The City
Pasquale mentions as a thing of interest we would assign an identifier to
which could be used to link to other objects containing information about
it, a record containing population, the name of the mayor, temperature
forecast for today etc.

Should we not think of the geometry representing the shape of the city in
the same way, one record contains it geometry as modelling for small scale
map production (a 1D point), another record the geometry associated with a
midscale web mapping product (2d Polygon), we can cope with a city having
multiple football teams linking to the different information records for
each team, why not different geometries ?

Ed


On Tue, 16 Feb 2016 at 09:45 Erik Wilde <erik.wilde@dret.net> wrote:

> 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    |
>
> --

*Ed Parsons*
Geospatial Technologist, Google

Google Voice +44 (0)20 7881 4501
www.edparsons.com @edparsons