[Geojson] My biggest beefs with GeoJSON

[Matthew Giger]

On Sep 20, 2007, at 9:04 PM, Christopher Schmidt wrote:

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

Hmmm. A little insulting. I hope my suggestions didn't insult you or  
your work.
That wasn't the intention.


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

Agreed. Measure or altitude data should certainly be supported. How the
information is transmitted about the tuple size is the detail that is  
at issue.
Aesthetically, the list of lists is better as it is implicit rather  
than explicit.
I guess the speed tradeoff, to me, seems worth the extra ugliness.


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

For small datasets, it certainly doesn't matter and it is more  
elegant to have a
list of n dimensional coordinates.  I guess the question is where you  
want that
coordinate encapsulation happen. If you are just going to pass off  
the coordinate
tuple list structure as-is to it's final destination, then it is a  
win. However if you
have to do any processing like converting lat-lon to 3d points,  
georeferencing
or even just put them into a C++ struct for it's ultimate  
destination, you are sacrificing
speed and memory for aestetics. It really shouldn't be much harder to  
loop with
  a +2 or +3 increment and place each coordinate element rather than  
increment
by +1 and pass the whole tuple.


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

While it is true that they are grouped logically, there is no  
specification on how
to decode the format as it is just a text string. Everyone has to  
roll their own
parser to decode a WKT "LINESTRING(3 4,10 50,20 25)" so the  
efficiency is
up to how the programmer writes the decoder. That is my issue, JSON  
has a
very specific grammar, and having the off the shelf decoder be as  
efficient as
possible is very important in things like Javascript running in a  
browser. The
reason that JSON is so great is that you don't have the slow  
processing overhead
of XML.



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

I'm not sure what your disagreement is, but I agree that the Multi's  
are the
special case, but since they are specified and should be supported, the
singles become the special case.


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

It seems that I might be too late to the discussion for any  
meaningful input,
at least for changes of the magnitude that I'm suggesting.