[Geojson] Problem in Twitter's GeoJSON

[Raffi Krikorian]

wow - thanks for the heads up!  that's all absolutely great to know.

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

--
Raffi Krikorian
Twitter Platform Team
raffi at twitter.com | @raffi