[Geojson] FW: Features without geometry

[Christopher Schmidt]

On Tue, Oct 02, 2007 at 03:21:43PM +0100, Stephen Battey wrote:
> 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.

If you're not transmitting geometry, why is it 'Geo'?

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

Well, that seems relatively obvious, since a Feature without geometry in
GeoJSON is only two things:

3: The GeoJSON object must have a member with the name "type". This
member's value is a string that determines the type of the GeoJSON
object.
3.4: A GeoJSON object with the type "Feature" represents a geometry with
additional properties (referred to as a feature object below). 
3.4.2: A feature object must have a member with the name "properties".
The value of the properties member is an object (any JSON object).

When you take away geometry, there isn't much left *in* GeoJSON.

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

Okay. So you're delivering a feature that fits the above 3 criteria --
you just don't call it a GeoJSON feature. It's just a Feature object in
JSON.

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

Completely agreed! But clients can speak something other than GeoJSON to
do that. GeoJSON isn't the end-all, be-all of JSON serialization -- it's
just a complete way to describe your geographic features. 

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

When you're asking the server for information about a feature, it can
return a feature specific to that information: in this case, the
attribute + centroid information defines the feature, where another
request might use the full geometry, or the bounding box, to define it. 

Without a geometry, it's not GeoJSON. It's just another JSON
serialization. If you want to describe it in terms of GeoJSON, that's
fine, but for interchange of data, having a geometry means that you know
what can be done with it.

Regards,
-- 
Christopher Schmidt
MetaCarta