I took a look at this. The geohash approach is not really the same approach we have for spatial hash queries.

Our current approach builds a bounding box and defines a list of hashes covering this bounding box.

The geohash approach only allows to define a unique geohash (by defining a point and a precision) and potentially the neighbors of this geohash (using neighbors = true). I don't think we can make it work in the same spirit of our current approach and IMHO the geohash approach is not precise enough for our use case.

The geohash approach has 2 majors drawbacks:

• if the point is at the border of a geohash (and you don't really know it), you really need to include the neighbors;
• if you include the neighbors, you really lose the precision.

This problem is far less present with the current approach which is indeed quite clever and adaptable.

I thought about having an intermediate approach when we would calculate the geohashes for an approximate bounding box but we can't query on several geohashes at the same time (the underlying query supports it as it has to support the neighbors feature but not the JSON API).

IMHO, there are two viable alternatives:

• we simply use a bounding box for hash queries. It might be fast enough.
• we use the very same approach used with Lucene and we index an additional field with the hash cell ids.

WDYT?