[Geojson] My biggest beefs with GeoJSON
mgiger at earthbrowser.com
Thu Sep 20 21:52:29 PDT 2007
On Sep 20, 2007, at 9:04 PM, Christopher Schmidt wrote:
> That's 100,000 lists containing 400,000 floating point numbers. I
> 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
That wasn't the intention.
> Not everything is flat. Not everything is even 3D. 3D with measure
> *does* exist, as does 3d data without it -- and the latter is becoming
> more and more common with these silly globe viewers that everyone
> 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
Aesthetically, the list of lists is better as it is implicit rather
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
> of coordinates in a pair!" Which I don't like any better, but I'll
> that there is little technical reason to use one over the other, as
> as I'm aware. However, in every piece of code i'm going to write, I
> to convert them to lists-of-lists *anyway* -- Whether that's inside
> 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
> 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
> 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
coordinate encapsulation happen. If you are just going to pass off
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,
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
a +2 or +3 increment and place each coordinate element rather than
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
up to how the programmer writes the decoder. That is my issue, JSON
very specific grammar, and having the off the shelf decoder be as
reason that JSON is so great is that you don't have the slow
>> 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.components
> LineString: geometry.components
> 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
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
at least for changes of the magnitude that I'm suggesting.
More information about the Geojson