[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