[GeoJSON] New, improved polygons

Tim Schaub noreply at geocartic.com
Wed Apr 25 10:18:27 PDT 2007


Hey-

Rambling response below.  Summarized at the end.

Allan Doyle wrote:
> Sean, Jason, and I came up with a new, improved polygon:
> 
>    "geometry": {
>      "type": "Polygon",
>      "crs": "EPSG:4326",
>      "coordinates": [[0.0,0.0],[1.0,0.0],[1.0,1.0],[0.0,1.0],[0.0,0.0]],
>      "holes":[[0.25,0.25],[0.75,0.25],[0.75,0.75],[0.25,0.75], 
> [0.25,0.25]]
>    }
> 
> Where "holes" is optional.
> 
> The idea is that this way, Point, LineString, Polygon, Box, and  
> MultiPoint all have very similar structures.
> 
> The question came up about why split holes from coordinates, why not  
> make Polygon coordinates be an array of rings. My answer is that if  
> we keep it like this, then coordinates are always arrays of arrays  
> (i.e. arrays of points).
> 
> Any objections? I'll toss this into RFC-001...

Hmm.  I'll register my objection.  Though I see why it seems neat to 
have points, lines, polygons, and multipoints all look very similar - I 
think it's an artificial requirement.

We've got agreement that a geometry object has a type string and a 
coordinates array.  I think the most logical structure for geometry 
objects would be something like this:

Point
-----
{
     "type": "Point",
     "coordinates": array
}
where the Point coordinates array is an array of 2 or more values 
representing coordinates in 2 or more dimensions.

MultiPoint
----------
{
     "type": "MultiPoint",
     "coordinates": array
}
where the MultiPoint coordinates array is an array of Point coordinate 
arrays as described above.

LineString
----------
{
     "type": "LineString",
     "coordinates": array
}
where the LineString coordinates array is an array of Point coordinate 
arrays as described above.  A LinearRing is a special LineString where 
the first and last points are equivalent (the ring is closed).

MultiLineString
---------------
{
     "type": "MultiLineString",
     "coordinates": array
}
where the MultiLineString coordinate array is an array of LineString 
coordinate arrays as described above.

Polygon
-------
{
     "type": "Polygon",
     "coordinates": array
}
where the Polygon coordinates array is an array of LinearRing coordinate 
arrays.  The first item in the coordinates array is the exterior 
LinearRing - any other items are interior LinearRings (holes).

MultiPolygon
------------
{
     "type": "MultiPolygon",
     "coordinates": array
}
where the MultiPolygon coordinates array is an array of Polygon 
coordinate arrays.

That's it.  Want a GeometryCollection?  That is a feature collection object.
{
     "features": array
}
where each feature in the array has a geometry object that is one of the 
  geometries described above.

This gets rid of the "members" and "holes" names - for which I see no 
need.

This also means that the "coordinates" arrays have different structures 
for each geometry type (I like "data" better - but I see that nobody 
else does).  I see that you can write a parser with fewer lines if you 
give Point, MultiPoint, LineString, Polygon, and Box the same 
coordinates array structure.  Since you still need lines to deal with 
the weirdly different MultiLineString, MultiPolygon, and Polygon with 
holes, I don't see the point.

So in summary:

I think "holes" is unnecessary.  Make the Polygon coordinates array an 
array of LinearRing coordinate arrays and you're done.  First item is 
exterior, rest are interior - done.

I think "members" is funky.  Since MultiPolygons can only be composed of 
Polygons, there is no reason to have the entire geometry object repeated 
(with the "type" value always "Polygon").  Make the MultiPolygon 
coordinates array an array of Polygon coordinate arrays (instead of 
geometry objects).  Same for MultiLineString.  Same for MultiPoint.

I think GeometryCollection is unnecessary.  We're already talking about 
sending arrays of geometry objects in the features array.  A 
GeometryCollection is not a multi-part geometry.  It is a collection of 
geometries.  In GeoJSON, it is represented by a collection of features. 
  As it is now, GeometryCollection looks very much like MultiPolygon but 
MultiPolygon looks very different from MultiPoint.  This is weird.

Again, I've heard the argument that you can cram much of your parser 
into one line if you keep the coordinates array identical for 5 of the 
geometries.  Personally, I think this argument is a bit weak - and makes 
the data structure overly funky.

My 2 bucks.
Tim



More information about the GeoJSON mailing list