8 comments

[ 4.5 ms ] story [ 28.0 ms ] thread
When the prefix (or infix) doesn't match for something that is close it looks like the prefixes are simply inverted. So 10000 and 01111 are obviously close. I haven't verified.
There is another free library to do that, among other things, by Google. It's not well known, but it was used all over the place internally (at least by the geo team).

https://code.google.com/p/s2-geometry-library/

The key difference with geohash is that it uses a Hilbert curve instead of a z-curve and it projects the world in a cube instead of using directly cartesian coordinates.

It only attempts to "allow you to sort locations by proximity", as explained in the article.
If you like this stuff, have a look at Healpix: http://healpix.sourceforge.net/ It splits sphere into pixels each with separate number. It is sort of fast hashing for spherical purposes in astronomy. It does not require trigonometric operations and is very fast.
Or to get rid of fault lines you can store two geohashes - the second one shifted so between the two, you can find many more "near points".

That said, geohashes like this are bad because they rely on lat/long without normalizing for distance first