[Geojson] Features without geometry
Stephen Battey
Stephen.Battey at dottedeyes.com
Fri Sep 21 01:51:49 PDT 2007
I wasn't looking to add geometry into existing JSON data structures, but
that is an approach that I could take.
We currently do something similar with GML. GML being so bulky we try to
save on the size of data by just using GML fragments where ever spatial
data is needed. I was not intending to use GeoJSON in the same way
because, with the exception not defining geometry for a feature, the
FeatureCollection structure describes exactly the data we want to send.
I would prefer, since I'm making wholesale changes to our data
interchange modules, to re-structure our existing JSON data into the
GeoJSON format. It would make life easier for our clients if we tell
them "data is returned as GeoJSON", rather than describe of our own
version of a spatially-enabled JSON data structure.
GeoJSON has clearly been defined with extensibility in mind. Items 2 and
3-4-2 in the spec allow developers to add in extra information while
still conforming to the GeoJSON format.
I think allowing geometry information to be optional follows the same
principle. It would give the data structure extra flexibility which
would extend its domain of use.
I'd like to gauge the pros and cons of the change I'm suggesting.
I've given an example of where specifying the geometry to be mandatory
causes a problem. Does anyone have any examples of where specifying the
geometry to be optional would cause a problem?
Steve
> -----Original Message-----
> From: geojson-bounces at lists.geojson.org
> [mailto:geojson-bounces at lists.geojson.org] On Behalf Of Andrew Turner
> Sent: 20 September 2007 16:12
> To: Stephen Battey
> Cc: geojson at lists.geojson.org
> Subject: Re: [Geojson] Features without geometry
>
>
> I agree (I think) with Stephen.
>
> GeoJSON seems to have defined it's own, stand-alone format
> that happens to be in JSON notation. This is different from
> GeoRSS which merely added geographic extensions to the RSS &
> Atom formats (and uses XML notation).
>
> What I think Stephen is looking for, and I would be to, is
> merely a path for using GeoJSON to "add geometry" to more
> complete JSON objects. This is "flipped" from what the last
> example on the draft is
>
> e.g.
>
> {
> "@namespaces": {"":"geo":"http://geojson.org/ns#",
> "atom":"http://www.w3.org/2005/Atom"},
> "blog" : {
> "posts" : [
> {
> "type" : "atom:item",
> "atom:summary": "post 1",
> "atom:description" : "i love blogging"},
> {
> "type" : "atom:item",
> "atom:summary": "post 2",
> "atom:description" : "i love geoblogging"
> "location" : {
> "type", "geo:Point",
> "geo:coordinates": [-120, 40]
> }
> },
> ],
> "location" : {
> "type", "geo:Box",
> "geo:coordinates": [[-121, 39], [-119, 41]]
> }
> }
> }
> }
>
> On 9/20/07, Stephen Battey <Stephen.Battey at dottedeyes.com> wrote:
> > A bit of background might help my explanation:
> > At the moment we have 2 actions on our server using JSON to
> transfer
> > information about features. The JSON structures were moulded around
> > the information being returned by the 2 actions. This lead to 2
> > different JSON structures. But now that we've decided to
> roll out JSON
> > to all our actions we're looking to adopt a common structure.
> >
> > Most of our actions will be passing features with spatial data, but
> > for some the geometry is not required. We see the definition of
> > geometry as an unnecessary overhead in these responses,
> which could be
> > sending back 100s of features with complex geometry. It
> does not make
> > any sense to define a completely different JSON data structure for
> > these actions. So we would continue to use GeoJSON's
> FeatureCollection
> > to define the set of features, which at least makes that
> part of the
> > data structure consistent across all our actions.
> >
> > So, in answer to your question, if we weren't representing spatial
> > data we'd still want to use GeoJSON to define a set of
> features (i.e.
> > use the specification of the FeatureCollection object).
> >
> > Omitting the geometry is not a huge problem for us
> internally, we'll
> > just not set the geometry member when not required and write our
> > client-side parser to handle no geometry. However, it would be a
> > problem for our customers who write their own client
> applications that
> > connect to our server. We'd like to tell them our server
> responds with
> > GeoJSON and for them to be able to use any GeoJSON parsing software
> > they choose. But if GeoJSON parsers strictly apply the GeoJSON spec
> > they will fail to read the data we send when the geometry member is
> > omitted.
> >
> > It seems inconvenient for developers using GeoJSON to have to
> > customise or write their own parser to handle a small
> non-conformance
> > like this. If the geometry member was optional what would be the
> > practical implications? After parsing a GeoJSON string developers
> > would need to check if a feature object had a geometry
> property before
> > trying to read its geometry. Are there are any further
> ramifications?
> > I'm trying to avoid it, but this re-opens the discussion of whether
> > the "type" member is required. If "geometry" is optional the "type"
> > member is necessary to identify a feature.
> >
> > Steve
> >
> >
> > -----Original Message-----
> > From: geojson-bounces at lists.geojson.org
> > [mailto:geojson-bounces at lists.geojson.org] On Behalf Of Tim Schaub
> > Sent: 19 September 2007 18:12
> > To: geojson at lists.geojson.org
> > Subject: Re: [Geojson] Features without geometry
> >
> >
> > Stephen Battey wrote:
> > > I'm looking into integrating GeoJSON into our web mapping
> > > application to replace the JSON data structure we currently use,
> > > which does not
> > follow
> > > any standards.
> > > One problem I foresee in adopting GeoJSON is there is no option to
> > omit
> > > geometry from features. The GeoJSON spec states:
> > > 3-4-1 A feature object must have a member with the name
> > "geometry".
> > > However, there are instances where we would like to
> transfer feature
> > > information without defining the geometry of those features, which
> > would
> > > just add extra overhead.
> > >
> > > For example, our client application has a "get info"
> tool, where the
> > > client will request information for features at or near a
> point or
> > > region. The response from the server is a set of features but for
> > > the purposes of this action the geometries of the features is
> > > irrelevant. The client application just wants to retrieve the
> > > properties of the features and display them to the end user. Our
> > > mapping application currently allows the client to specify in the
> > > request whether they would like geometry information
> included in the
> > > response. Historically, this is because we originally
> used GML, so
> > > having geometry in the response made the response roughly 110%
> > > larger than without. Although GeoJSON will be
> significantly smaller
> > > than GML the same logic still applies - the response is
> roughly 70%
> > > larger with
> >
> > > geometry than without.
> > >
> > > Does it make sense to omit the geometry member in GeoJSON? Should
> > > geometry be treated as just another piece of information or is it
> > > more
> >
> > > fundamental to the definition of a feature?
> > > Conversely, does it make sense for a GeoJSON parser to throw out
> > > data
> > as
> > > invalid GeoJSON simply because the geometry information is missing
> > when
> > > all other aspects of the GeoJSON structure are correct - so the
> > > parser could continue parsing, having set the geometry
> attribute to
> > null
> > > or left undefined?
> > >
> >
> > Geometries are really the heart of GeoJSON. The spec says that a
> > feature "represents a geometry with additional properties."
> >
> > Features are really pretty weak in GeoJSON. The properties
> object of
> > a feature can be anything you want. So, without the geometry, a
> > feature doesn't really have any structure.
> >
> > In my mind, if you omit the geometry from GeoJSON, you're
> just back to
> > JSON. Can you describe what you'd get out of switching to
> GeoJSON if
> > you weren't representing spatial data?
> >
> > Tim
> >
> > > Steve
> > >
> > > __________________________________________________
> > >
> > > *Stephen Battey*
> > > *Software Engineer, Development Team, Dotted Eyes Ltd*
> > > __________________________________________________
> > >
> > > Dotted Eyes +44 (0)1527 556920
> > > Hanbury Court, Harris Business Park,
> > > Stoke Prior, Bromsgrove B60 4JJ, UK
> > >
> > > *Location. Precision. Vision. *www.dottedeyes.com
> > > <http://www.dottedeyes.com/>*
> > >
> > > *ResponseMX dynamic web maps: www.dottedeyes.com/rmx
> > > <http://www.dottedeyes.com/rmx> Ready-to-use digital maps & data:
> > > www.dottedeyes.com/digital <http://www.dottedeyes.com/digital>
> > >
> > > This email may contain confidential information, not to be
> > > disclosed. Contents are personal and not necessarily the views of
> > > Dotted Eyes. Emails and attachments may be monitored
> without notice
> > > in advance.
> > >
> > >
> > >
> > > Email has been scanned for viruses and spam by Altman
> Technologies
> > > <http://www.altman.co.uk/emailsystems>
> > >
> > > !DSPAM:4033,46f0eabc271862143011171!
> > >
> > >
> > >
> >
> ----------------------------------------------------------------------
> > --
> > >
> > > _______________________________________________
> > > Geojson mailing list
> > > Geojson at lists.geojson.org
> > > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> > >
> > >
> > > !DSPAM:4033,46f0eabc271862143011171!
> >
> > _______________________________________________
> > Geojson mailing list
> > Geojson at lists.geojson.org
> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> >
> > Incoming e-mail scanned by Altman Technologies
> > Email has been scanned for viruses and spam by Altman Technologies
> > _______________________________________________
> > Geojson mailing list
> > Geojson at lists.geojson.org
> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> >
>
>
> --
> Andrew Turner
> ajturner at highearthorbit.com 42.2774N x 83.7611W
> http://highearthorbit.com Ann Arbor, Michigan, USA
> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
> Incoming e-mail scanned by Altman Technologies
>
Email has been scanned for viruses and spam by Altman Technologies
More information about the GeoJSON
mailing list