[GeoJSON] Aligning implementations

Arnaud Diederen ad at ionicsoft.com
Tue Apr 10 00:31:18 PDT 2007


 
Hello everyone,
 
[my name must be very new to members of this list, but I've been reading this thread for quite some time, and since I have some experience with the topic, I thought I'd share it with you]
 

________________________________

From: geojson-bounces at lists.geojson.org on behalf of Chris Holmes
Sent: Sat 4/7/2007 7:07 PM
To: geojson at lists.geojson.org
Subject: [GeoJSON] Aligning implementations



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],
   }
}


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?

 

IMHO, there's no advantage at all. 

Making use of the geometry will be _much_ more costly than digging in the property array anyway. 

Typically, you'll want to do things like:

  * Showing the envelope/footprint of the geometry on the map (therefore toying with the DOM tree of the browser)

  * Edit that geometry (toying with the DOM + computations + all-the-logic-inside-to-allow-that)

Both those are more costly than a simple lookup in an array of objects.

Moreover, in the WFS's XML output representation, a geometry is a property like any other. I don't think there's a good reason to not follow that convention.

Now, about "designing the default geometry property": I think that kind of information should be present in the feature type information. If you mean to do anything solid with features in the browser, you'll need that information anyway, so I think it'd be a good idea to put that extra bit in that place.

Best regards,

           Arnaud

 

 



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

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20070410/40dcf27e/attachment.htm>


More information about the GeoJSON mailing list