[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