[GeoJSON] spec clarification of CRS

Raj Singh raj at rajsingh.org
Sun Dec 15 19:25:26 PST 2013


I totally see why you would want to require x, y ordering to lessen the developer implementation load. IMHO losing support for some CRSes to have unchanging coordinate order is a tradeoff that makes plenty of sense. I only disagree with using part of a CRS. My general feeling is that people who don't know that a CRS impacts coordinate ordering probably don't know what a CRS is anyway, and are just using what many like to call "GPS" coordinates. Telling them to put coordinates in as x, y is enough. 

And I actually think it's quite clever and useful to only have x, y in GeoJSON. I'll just never be comfortable with this partial use. But that being said, I also think what works well in practice should win the debate, so if the partial CRS story proves useful and not confusing I'll stand corrected.

---
Raj

On Dec 13, at 12:38 PM, Howard Butler <howard at hobu.co> wrote:

> 
> On Dec 13, 2013, at 7:50 AM, Raj Singh <raj at rajsingh.org> wrote:
> 
>> I disagree with that decision -- it doesn't make any sense to me to allow the use of part of a CRS definition -- but at least now I understand what's going on. 
> 
> But do you understand why the choice was made and can you recognize the benefits it has had in terms of lessening the developer load to implement? The dereferencing of an SRS to determine coordinate ordering has a big cost. It adds complexity for the implementor (how do I figure out the coordinate ordering?) and requires external coordination and agreement of the producer and the consumer to use the data. Because of this choice, for the majority of scenarios, GeoJSON's interoperability failure story is mostly some wonky lat/lon mixups when someone is manually bootstrapping things. This simpleness is key to its widespread and unsupervised adoption.
> 
> SRS as it exists now in GeoJSON is a failure of hoping things will work out. In hindsight it would have been better to only allow x,y EPSG:4326 and EPSG:900913. stop. But we can't undo it now, either.
> 
> Howard




More information about the GeoJSON mailing list