[GeoJSON] Aligning implementations

[Philippe Duchesne]

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

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