Have added details regarding data generation to the README.

Well if you have used geohashes, have an idea of the all use cases, you would know the purpose. :)

One sample use case would be, if you want to find which polygon (building or administrative regions like states or cities) a given location falls into, doing a point in polygon for a huge set wouldn't be the best solution. Here comes the use of geohash and s2 cells. Using GeoRaptor on the initial set of geohashes reduces the search space considerably. For instance, the entire shape of the US creates 18 million geohashes which get reduced to ~220K when compressed.

> hashes don't lend themselves well to stemming for use in text-based searching

I didn't get this completely. :)

This was something that hadn't been solved using geohashes. Intention was to just bring out 'geohash'y of solution to proximity search.

Hi, yes I am familiar with the s2 cell library. The whole intention was to bring in a similar feature for Geohash, which by default cover only rectangular regions. :)

You can decode the hash back to the location coordinate. In fact if you look at the code, you'll see that the output is a set of points which are then geohash encoded in order to get the hashed value.

Would surely go through the blog mentioned. Thanks.

It's not ProximityHash that does the optimization. There's an option to use Georaptor which does the optimization. Please have a look at GeoRaptor (https://github.com/ashwin711/georaptor).

On your second question, it completely depends on the problem at hand. I have been using GEORADIUS on Redis for around a year now @ > 30k QPS. The case there is to find locations that are closest to our input. ProximityHash provides you all the geohashes in a circular area for which I haven't found a library yet. Most of them provide geohashes in a BoundingBox.