[Geojson] Features without geometry
Andrew Turner
ajturner at highearthorbit.com
Thu Sep 20 08:11:43 PDT 2007
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
More information about the GeoJSON
mailing list