[GeoJSON] Aligning implementations

Sean Gillies sgillies at frii.com
Sat Apr 7 12:18:01 PDT 2007


Chris Holmes wrote:
> Ok, I'd like to take a shot at lining up the proto-implementations and 
> perhaps putting some words down on the wiki.
> 
> The big open question for me right now is if geometry is a top level 
> property, as in OpenLayers/PCL at the moment
> 
> {
>   'id': '1',
>   'properties': {
>     'title': u'Feature 1',
>     'summary': u'The first feature',
>     'link': http://example.org/features/1,
>   }
>   'geometry': {
>     # WGS84 crs is implied
>     'type': 'Point',
>     'coordinates': [-105.8, 40.05],
>   }
> }
> 
> Or do we want geometry as just one of the properties:
> 
> {
>   'id': '1',
>   'title': u'Feature 1',
>   'summary': u'The first feature',
>   'link': http://example.org/features/1,
>   'geometry': {
>     # WGS84 crs is implied
>     'type': 'Point',
>     'coordinates': [-105.8, 40.05],
>   }
> }
> 

Clarification: the above (from 
http://trac.gispython.org/projects/PCL/wiki/PythonFeatureProtocol) is 
actually Python, but looks a lot like JSON.

> 
> Is there some javascripty advantage to putting geometry as a special 
> property?  I suppose it makes it easier to get at the geometry, not 
> having to dig in to the property array?
> 
> I think one potential issue with geometry as a top level property is 
> what if you have a feature with more than one geometry?  This is 
> certainly not that uncommon (though I concede it does break us out of 
> 'simple features'), like including the bounds with the geometry (which 
> we could do with a special envelope property), or say a feature that has 
> both the lot geometry and the building geometry.
> 
> Thoughts?  I'm fine with either, I just never heard explicit 
> justification for the change to geometry on the top level.
> 
> Chris
> 

Easy access to the geometry is the only justification (for me). A 
top-level geometry wouldn't preclude putting other geometries in the 
properties object under other names.

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:

{
   'id': '1',
   'envelope': {
     'type': 'Point', # Envelope of all geometries is a point
     'coordinates': [...],
   }
   'properties': {...}
}

and that's a degraded case of your more complex one:

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

Cheers,
Sean

-- 
Sean Gillies
http://zcologia.com/news




More information about the GeoJSON mailing list