[Geojson] My biggest beefs with GeoJSON
Matthew Giger
mgiger at earthbrowser.com
Thu Sep 20 20:16:21 PDT 2007
I love JSON and am really benefiting from the data transparency and
would like to help make GeoJSON better. I'd really like to use
something that has at least some sort of standardization for some new
vector datasets that I am producing, however during implementation I
have run up against a couple of issues with the spec as it is now.
First and most importantly, the restriction that each coordinate
tuple is contained within it's own list. That's fine for small
features, but for something like a state boundary, there are tens of
thousands of coordinates involved. Each which must have it's own list
object containing the coordinates. The state of Alaska has over
100,000 points of data, which means over 100,000 lists containing
over 200,000 floating point numbers. Can we just get rid of those
100,000 constant size lists that take time to create and dereference
and needlessly take up memory? It has been suggested that I write
custom JSON decoding code to take care of that problem, but I think
that the GJ spec should work efficiently with standard off the shelf
encoders/decoders. Put all coordinates into a single list for the
LineString and Polygon please.
The second issue is the Point, LineString and Polygon types, each of
which have an analogous MultiPoint, MultiLineString and MultiPolygon.
I find myself writing special case code to see if it is a LineString
and then enclose that single item within a list and pass it on to my
MultiLineString class since a LineString is really just a special
case of a MultiLineString with one element. Do I really have to write
code to take care of those special cases of single element geometry
types? Can we just get rid of them and rename the Multi* geometries
as plural "Points", "LineStrings", "Polygons"?
Oh, and what's up with "Box"? Isn't it just a MultiPoint?
I guess that's enough for now...
More information about the GeoJSON
mailing list