[Geojson] Problem in Twitter's GeoJSON

[Christopher Schmidt]

On Tue, Nov 24, 2009 at 09:30:56AM -0800, Raffi Krikorian wrote:
>> Twitter has crossed up easting and northing in their API docs, and I
>> see it in their API responses too. Can anybody following this list get
>> the word to those developers?
>>
>> --
>> Sean Gillies
>> Programmer
>> Institute for the Study of the Ancient World
>> New York University
> hmm. it does seem like we have it reversed -- we're sending northing  
> then easting in our coordinates.  thanks for letting us know!
>
> just out of curiosity, why is this represented as so, when GeoRSS has a 
> point defined as a latitude-longitude pair? 
> http://www.georss.org/simple#Point.

"Becasue GeoRSS does it wrong"? :)

More seriously, GeoRSS is the reverse of several other popular geodata
formats: for example, KML has x, y, GML has x,y in most cases, etc. 

GeoRSS uses y, x in some cases, not all: GeoRSS "where" elements (which
depend on GML) will often use x, y (I believe), at least for some projections.

In OGC-based specs, there is a common trend right now to follow the
"axis order of the underlying coordinate system definition". (GIS data
can be in many projections -- GeoJSON was specifically designed with
this in mind.) Unfortunately, to support this type of usage, any client
must have a full definition of every coordinate system it wants to display/
parse, and the axis order it uses.

Since GeoJSON data can be in many different projections -- basically an
unlimited number, and there is no requirement for them to exist in any
'standard' coordinate reference lookup -- this would needlessly complicate
clients, so we ignored the 'axis order can change', and instead went
with the most common coordinate ordering in GIS software, where GeoJSON
was expected to be most prevelant. This common axis ordering is "x, y" --
the same coordinate ordering you learned in grade school, most likely.

The most common geographic coordinate system -- EPSG:4326 -- is defined
as having an order of y, x. However, there is a lot of history and software
which has canonically ignored this, and gone with 'x, y' for everything.
(Most GIS is probably based at least in part around having projected system
support, where 'x, y' or 'easting, northing' is more common.)

So, it came down to a choice: Did we do what was common among non-GIS folk,
and was encouraged by EPSG/OGC for geographic data, but not projected data?
Or did we follow the more common ordering prevelant in much of the (at 
least, Open Source) GIS software for canonical ordering? (A third option,
allowing the ordering to change with the projection, was never really
considered, due to the considerable complexity it introduces.)

In the end, we went with the standard GIS representation, figuring that
most things reading/writing GeoJSON would be tools, and not people. With
that being the case, picking something that is relatively common (again,
see KML, GML, WKT, etc.), and fits the paradigm usually created by those
tools, is what we thought was best.

Best Regards,
-- 
Christopher Schmidt
MetaCarta