[Geojson] Features without geometry

Thu Sep 20 07:31:44 PDT 2007

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