[Geojson] FW: Features without geometry

[Stephen Battey]

I still think there is a problem with the geometry member in the Feature
object. Defining that member to be mandatory makes using GeoJSON to
transmit information about features more restrictive than it needs to
be.


I've been discussing this issue with the other developers in my team.
We asked some tough questions - including whether GeoJSON is the right
tool for us. We considered defining our own data structure, but the spec
is so close to GeoJSON that any structure we defined would be best
described to clients as 'GeoJSON with a slight twist'.
While we all agreed that you wouldn't want to define a feature without
geometry we couldn't get around the fact that you don't want to transmit
the geometry in every data packet.


It seems there is a subtle difference in intent. GeoJSON specifies a
structure for *defining* a feature, while I need a structure for
*interchanging* feature information.

The difference of purpose is slight but significant.
To illustrate the difference, suppose you were creating a table in a
database to store documents. You would probably make the file field
mandatory, so anyone defining a document has to specify a file. But when
someone queries that table you wouldn't force them to retrieve the file
object for each record. The query should be able to select the
information relevant to the task in hand - in some cases just the
document's metadata (a list of titles and authors, say).

In short: although some information is mandatory for the definition of
an entity, whether that information is included in a data exchange
should be determined by the client, who knows which information is
relevant.


I'd prefer GeoJSON to have the flexibility to send data like this:
{
   "type": "Feature",
   "geometry": {
       "type": "Polygon",
       "coordinates": [
           [
               [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0],
[100.0, 0.0]
           ]
       ]
   },
   "boundingbox": {
       "type": "Box",
       "coordinates": [
           [100.0, 0.0], [101.0, 1.0]
       ]
   },
   "centroid": {
       "type": "Point",
       "coordinates": [100.5, 0.5]
   },
   "properties": {
       "prop0": "value0",
       "prop1": "value1"
   }
}

where the geometry, boundingbox, centroid members of the Feature object
are all optional.

E.g.

If an application wants to label features on a map it can retrieve just
the relevant information for each feature:
{
   "type": "Feature",
   "centroid": {
       "type": "Point",
       "coordinates": [100.5, 0.5]
   },
   "properties": {
       "prop0": "value0"
   }
}


Steve


-----Original Message-----
From: Stephen Battey 
Sent: 21 September 2007 09:52
To: geojson at lists.geojson.org; 'Andrew Turner'
Subject: RE: [Geojson] Features without geometry


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