[GeoJSON] Aligning implementations

[Allan Doyle]

On Apr 13, 2007, at 11:01, Philippe Duchesne wrote:

> Hello all,
>
> i'm joining this thread a bit late, but i'm wondering why the proposal
> from Chris hasn't received more comments, since it looks like a nice
> compromise to me.
>
> So the proposal was having 'default_geom' that refers to one of the
> properties in the 'properties' array  :
>
>   {
>      'id': '2',
>      'default_geom': 'building'
>      'properties': {
>        'owner': 'Pete'
>        'lot':      {'type': 'Polygon', ...},
>        'building': {'type': 'Polygon', ...},
>      }
> }
>
> I'm also in favor of being able to have [0..n] geometries in a
> feature; in the case of a feature that holds no geometry, one could
> have :
>
> {
>      'id': '2',
>      'default_geom': null,
>      'properties': {
>        'owner': 'Pete'
>      }
> }
>
> To answer Tim's concerns about the fact that this solution implies two
> lookups to get the default geometry, i would say that, on the other
> hand, i'd really avoid having duplicate data in the feature, which is
> the case if we choose to have
>   {
>      'id': '2',
>      'geometry': {'type': 'Polygon', ...}
>      'properties': {
>        'owner': 'Pete'
>        'lot':      {'type': 'Polygon', ...},
>        'building': {'type': 'Polygon', ...},  // same polygon data as
> for 'geometry'
>      }
> }
>
Maybe flip it around and have

   {
      'id': '2',
      'geometry': {'type': 'Polygon', ...}
      'properties': {
        'owner': 'Pete'
        'lot':      {'type': 'Polygon', ...},
        'building': 'default'  // same polygon data as for 'geometry'
      }
}

That way, only the people who want alternate geometries have to pay  
the price of dealing with them.


> Allan, to answer your point about the fact that here, 'lot' is
> actually an implicit subfeature of building, i would give another
> example : consider a 'country' feature, that needs to contain both the
> 'boundingbox' geometry and the 'borders' polygon, and where usually
> the boundingbox is not simply the envelope of the borders. There, we
> have two geometries that are equally relevant for the feature.

My one point was that perhaps instead of alternate geometries, a  
feature can have sub-features in the properties. Then you can  
recursively unpack things.

My other, later point was that if we make the contents of properties  
be entirely optional, then people can agree on what they want to do  
with them, including any alternate geometry scheme.

Maybe once there's widespread acceptance, then the people who like it  
can define a spec.

	Allan

>
> my 2c,
>
> --p.
>
> On Apr 10, 2007, at 23:51, Martin Daly wrote:
>
>>> Allan, it may be a free-for-all in the properties attribute,
>>> and that would be just fine. Remember, JSON is about simple
>>> data structures, not about documents. If an application needs
>>> strict semantics and hierarchy, XML is a much better choice.
>>
>> +1 on simplicity.
>>
>> I'm concerned that some of what has been discussed over the past few
>> days is loading every feature with (self-describing) metadata.  If  
>> there
>> is need for such metadata, then wouldn't it be better at the
>> features/featurecollection level?  Even then, aren't we in danger of
>> doing XML-in-JSON by devising our own JSON Schema?
>>
>> If anyone had a bright idea how to do the simple, one geometry per
>> feature (optionally null), case without precluding multiple  
>> geometries
>> in future, then I would be tempted to go for that first.
>>
>> M
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org