So far the code was simplified and polished, fixed (it did not returned the right set of elements in all the cases), GEORADIUS speed was improved.
On the other side I removed all the JSON things and the Pub/Sub (IMHO is interesting to subscribe to areas to see objects entering/exiting them, not much to position updates since it's the same of doing PUBLISH+GEOADD from the client side).
Added: GEOHASH to return a Geohash standard string from of a given element, mainly for interoperability. I'm also adding GEODIST (to calculate distances) and GEOPOS (to retrieve latitude/longitude of objects without the need to query for radius).
The work will be available in the context of Redis 3.2, unless I get mad and merge back into 3.0, which is unlikely but not impossible.
EDIT: before of three days ago I was not aware of Geohashing at all, so if you have five mins to check the code, I'll be glad :-) Thanks. I'm pretty confident that it's ok now after I added a fuzzy test that replicates the feature (by brute forcing distance computation) in Tcl that checks against the Redis output, but still...
EDIT2: wanted to add that I'm very glad Matt efforts are not going to be wasted and we are finally merging this.
Dynamic Redis seems like a decent project and would make hacking core functionality fun and simple.
So, despite the obvious perks that we'll enjoy by side-loading our own junk, antirez's "Quality or DEATH" approach on this matter leaves no open questions about the possible inclusion of this functionality. There is, however, another way to get code running in Redis... it is called a GitHub Pull Request :) If you've thunk up something really amazing/useful and coded it, drop by the redis-dev mailing list to discuss it, maybe do an RCP and submit your code. No one promises that your PR will be accepted, but even if it won't make its way into the core, anyone will be able to use it nonetheless.
Another point worth mentioning in this context is that in order to even contemplate such a mechanism, Redis' core will need heavy refactoring of the internal API. This is by all accounts a huge effort that, if taken by the developer, is likely to postpone a lot of other important work.
A related question: is there some kind of repo for "useful lua scripts that everybody could use but didn't make it in core redis (yet)" ?
Had Redis Geo been around at the time we replatformed at Hailo we would have given it some serious consideration. But instead we have developed our own solution and open sourced a library in Go called "geoindex" to store and retrieve geo information: https://github.com/hailocab/go-geoindex .
It's part of our core functions within our microservices stack. You can read more about it on our blog too: https://sudo.hailoapp.com/services/2015/02/18/geoindex/
I knew/know C but have been doing high level programming for years. Would anyone suggest if I wanted to visit this source tree, I check out an earlier version (like 1.x) or just jump straight to latest stable or master?
10/10 would read through again.
That said, I have also implemented large-scale point-in-plane indexing systems, though not in a while. Per CPU core, you can encode and index around 20M geo-points per second if the implementation is good.
Geohashed (X+Y) points in Redis is only peripherally related to actual geospatial database concerns, particularly big-data or ("NoSQL") spatial database concerns - how do you efficiently index anything other than point data (polygons, multi_polygons), or ask spatial queries (e.g., nearest neighbors) is not even close to being addressed.
Blog post here for reference: http://www.jandrewrogers.com/2015/03/02/geospatial-databases...
* 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.
oregon, for instance, has two official state spatial references (if top of memory is correct).
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. 
I always found their argument a little specious given that EPSG 4326 exists.
To be fair, if you look at most geo APIs (e.g. GMaps) and you just blindly copy values around without paying attention, you are more likely to be right if you were copying [y,x]. Mind you I say most and not all, since there are very popular geo libraries (e.g. Leaflet) that use [x,y] instead.
I would just pick something, make sure it is well documented and clear and just go with that.
I needed a limit parameter for the Georadius method because i wanted a result set sorted by distance in a large radius, but not have thousands of results send from the redis server to my webservers. Anyone interested in such a parameter can use my little fork for the Geo module:
Currently the Geo module only supports a range up to 20.000 km. So your idea does not work at the moment. I agree that those items are not really "nearby", but to be consistent through out the application it would be nice to be able to select without a max distance.
I researched geodb a while back and I only found PostGIS but I recently found out that elastic search also supports geo features.
Shameless plug - This is the simple API I built on top of PostGIS https://github.com/moo-mou/GeoGo
Since anyway the bounding boxes we calculate and the resulting areas we scan are larger than needed, so all the actual precision is in the filtering function that removes points outside the radius.
TLDR: It will be trivial to fix that later in a backward compatible way. Btw adding an item in my TODO in order to check if I can do it right now without compromising performances.
Or is it just assuming that the earth is a perfect sphere?
If you're curious about the topic, you can start here: https://en.wikipedia.org/wiki/World_Geodetic_System.
This extension adds geo-specific commands and storage to the list of operations supported.
People here are generous with their time, skills, and knowledge, but your initial question and your followup makes it sound like you've not even tried to educate yourself.
some uses for redis, as we use it:
* pubsub (publish/subscribe) - push information through to other servers on channels
* job queuing - redis supports lists, which can easily become job queues
* statistics - redis supports incrementing and decrementing keys very quickly and easily, allowing for real-time statistics gathering and reporting
hope that helps.
Yeah thank you. That looks like a message bus, but with many more features than just a bus.
My account is only 5 hours old because I created it to ask my question. I am relatively here and I was just lurking before.