Hacker News Reader

Comment by jerrysievert | Hacker News Reader

the issue is that you are now entering a different sector of technology, where there are already standards in place, and those standards are x, y, z ordering:

* mongodb geospatial extensions - http://docs.mongodb.org/manual/core/geospatial-indexes/

* postgresql geospatial extensions - http://postgis.net/docs/manual-2.1/

* geocouch - https://github.com/couchbase/geocouch/wiki/Spatial-Views-API

so, it isn't just GIS users who are doing this, it is also the convention across databases that support geo functionality.

i hope that you reconsider this, and don't go against what is both standard by committee and standard by implementation.

View on HN

Oh if it's a standard among implementations of databases consider this done. It will not be funny for people migrating from the module to the Redis implementation, but I can't be backward compatible with API that never entered Redis official code base after all... Thanks for pushing me into the right direction with your arguments.

thanks! i know that it is going to be harder for those migrating, but as they move into a more location-driven world, they'll ultimately be happier i think.

Damn, you're right about GIS databases. In my apps I always used lattitude first, as was taught in geography lessons, but you've convinced me to move from lattitude endian to longitude endian. Two choices - too many choices...

it gets worse. there are tons and tons of spatial references, and they can all be defined differently.

see: http://spatialreference.org

oregon, for instance, has two official state spatial references (if top of memory is correct).

Spatial References I can understand - when you want to create a map of a single country/region, a custom projection centered specifically around that region can provide a more accurate approximation of equal-distance points, parallel lines etc, something that is not possible with a worldwide projection.

Note that Redis Geo uses the infamous Web Mercator, used also by Microsoft Maps, Google Maps, OpenStreeMap, MapQuest, etc. but apparently rejected by the standards body EPSG with the declaration: "We will not devalue the EPSG dataset by including such inappropriate geodesy and cartography." Ouch. [1]

[1] https://en.wikipedia.org/wiki/Web_Mercator

But now accepted as EPSG 3857.

I always found their argument a little specious given that EPSG 4326 exists.

It is there: EPSG:3857

Reply on news.ycombinator.com