[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