[GeoJSON] A first implementation

[Martin Daly]

> The "coordinates" array here is interesting, in that it is a 
> one-dimensional array, of ( x1, y1, x2, y2, x3, y3, ... ). 
> Any thought to how (if) to handle higher dimensionality?  In 
> the type string ("MultiPolygonZ")?

MultiPolygonZ/MultiPolygonZM/MultiPolygonM would be OK for me, although
strict OGC-ness should mean that the CRS decides, with a "compound" CRS
for 2D + Z.

> On a similar note, any rules around case on the type strings?

I don't care about this one, and would probably end up doing
case-independent string comparisons anyway to catch the inevitable duff
data.

> On the type strings in general?

I would be tempted to mandate fixed type strings, and some others:

"features"
"crs"
"feature"
"geometry"
"coordinates" (or "data" if consensus goes that way)
"type" (as in geometry type)
"Point/LineString/Polygon" (etc., as the valid values of "type")
"members" (as in children of Multi[Point|LineString|Polygon], or use
"Points", etc.)
"properties" (if it remains a child of "feature")

"features" and "feature" feel the most contentious because I can see the
need for "roads" and "road", for example.

M