[GeoJSON] Aligning implementations

[Jason Birch]

Sean Gillies wrote:

> What would you think about an envelope attribute at the root that could 
> also serve as "the" geometry for the common, simple cases? Rewrite my 
> previous example as:

I like that idea, but what I have been doing so far is storing the 
envelope (bounding box) and centroid as separate top-level lists of 
positions.  I need both of these for different reasons.

Calculating the centroid of a bounding box is trivial, so if it's 
preferred to have only one top-level envelope property, I would prefer 
that the envelope be always specified as a box, and clients that need a 
point can generate it themselves.

> {
>    'id': '2',
>    'envelope': {
>      'type': 'Polygon',
>      'coordinates': [[...]],
>    }
>    'properties': {
>      'lot':      {'type': 'Polygon', ...},
>      'building': {'type': 'Polygon', ...},
>    }
> }

I hadn't considered this use case.  I'll likely have multiple properties 
per feature, but in the above case I'd likely supply the geometry for 
the lot at the top level, and then an array of id/uri pairs for the 
building properties rather than embedding them in the resource.

To allow for flexibility, maybe it would be best to continue to encode 
the geometry inside of a 'geometry' property.  This will allow the 
client to easily know when they're working with geometry, and would 
allow the geometry to be positioned at the top of the resource.

So, for the above example, each of the properties would have a 
'geometry' sub-property in addition to the other attributes.

Jason