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:
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...
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]
* 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.