[Geojson] My biggest beefs with GeoJSON

[Christopher Schmidt]

On Thu, Sep 20, 2007 at 08:16:21PM -0700, Matthew Giger wrote:
> 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.

That's 100,000 lists containing 400,000 floating point numbers. I mean,
300,000 floating point numbers. Wait, no, you're right. It's ust
200,000. No, you're wrong, it's 300,000!

Not everything is flat. Not everything is even 3D. 3D with measure data
*does* exist, as does 3d data without it -- and the latter is becoming
more and more common with these silly globe viewers that everyone keeps
using. Points are not always 2d.

Now, the next argument is to go with the "well then, specify the number
of coordinates in a pair!" Which I don't like any better, but I'll admit
that there is little technical reason to use one over the other, as far
as I'm aware. However, in every piece of code i'm going to write, I have
to convert them to lists-of-lists *anyway* -- Whether that's inside WKT,
GML, KML, or what have you. The geometric representations that I use are
all based on lists inside of lists. Making the spec match the common
implementation seems sane from my point of view implementing it in what
I have so far. The data that is coming out of GeoJSON isn't stored as a
geographic data structure -- it's ripped apart to give something that's
turned into a geographic data structure, and in general, it seems like
'lists of lists' is the right path for that.

GeoJSON is not designed to minimize size over the wire or optimize
parsing time. It's simply designed to be a set of common things that
most people can agree to. The list-of-lists is common throughout GIS:
WKT. KML. GML. The only thing that isn't is (maybe) GeoRSS. 

> 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. 

I would disagree with this. Inspecting the first coordinate pair of:
 MultiLineString: geometry.components[0].components[0]
 LineString: geometry.components[0]

Obviously, this is very implementation specific, but I don't see them as
'degenerate special cases' -- in fact, the inclusion of Multis at all is
accepting of Special Cases. The general case is the linestring case --
the MultiLineString is an anomoly.   

> 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"?

I'm strongly against that.

> Oh, and what's up with "Box"? Isn't it just a MultiPoint?

It's a simple polygon. (I'd be just as happy with it going away, and
software I've written doesn't support it.) 

Regards,
-- 
Christopher Schmidt
MetaCarta