[GeoJSON] AsJSON(geometry)

Sean Gillies sgillies at frii.com
Mon Mar 19 11:47:35 PDT 2007


Chris Holmes wrote:
>  >>> I think that's needlessly fluffy. Once you know the typology,
>  >>> you can deal with anonymous arrays-of-arrays perfectly well.
>  >>
>  >> I agree and prefer:
>  >>
>  >>     {"multipoint": "[[x00 y00], [x11 y11], ..., [xNN yNN]]"}
>  >>
> 
>  > This was my initial feeling too. But I've already got objects in hand
>  > with point members on the Python side of my application, and I'd like 
>  > an object or hash-oriented interface on the javascript side as well.
>  > Why should I pack them into anonymous arrays just to unpack them 
> again > at the other end?
> 
> I'm a bit more on the object approach as well.  I think it's a bit more 
> human readable, without really all that much fluff in the big picture.
> 
> A very small multi-polygon ends up something like this:
> 
> [[[[10,10][10,20][20,20][20,15][10,10]]][[[10,10][10,20][20,20][20,15][10,10]][[11,11][11,12][12,12][11,11]]]] 
> (two polygons, one just exterior, one with an exterior and an interior)
> 
> Also looking at OpenLayer's svn: 
> http://svn.openlayers.org/trunk/openlayers/lib/OpenLayers/Geometry/
> 
> there is a geometry object model, and I think it'd make sense to just 
> dump in to something like that.
> 
> I'm also +1 on rolling in geometryType and spatialCoordinates in to one.
> 
> Chris
> 

My preference for

   {"type": "point", "value": [x1, x2, x3]}

over

   {"point": [x1, x2, x3]}

is that geometry handling code can switch() on the value of "type" for 
the former. The latter looks more concise, but is less convenient to 
handle, requiring if/else or try/catch. IMO, a good geo-JSON should be 
ridiculously easy to use, even if it means being a bit fluffy.

Cheers,
Sean

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




More information about the GeoJSON mailing list