Geohash Encoder

Geohash folds a latitude and longitude into a short base-32 string by repeatedly halving the world and recording which half the point fell in. The bits alternate between longitude and latitude, five bits per character, so every character you add divides the cell by 32. Encode a coordinate to any precision from 1 to 12, decode one back with its bounding box, and see all eight neighbouring cells.

The property that makes it useful in a database is the prefix: two locations in the same cell share a prefix, so a LIKE 'u4pruy%' or a range scan on a sorted key finds everything nearby without a spatial index. Redis GEO, older MongoDB deployments and plenty of hand-rolled systems lean on exactly this.

The cells are not square, and the shape alternates. Because the bits alternate between the two axes, an even-length geohash has spent one more bit on longitude than latitude: precision 8 gives a cell about 38 metres wide and 19 tall at the equator, while precision 9 is roughly 4.8 metres in both directions. Precision 5 is about 4.9 km square and precision 12 is a few centimetres. If you are choosing a precision for a radius query, the number to reason about is the smaller dimension.

Two limitations to design around. Cells shrink toward the poles because a degree of longitude does: that 38-metre cell is 30 metres across in Seoul, 19 at 60° north and 13 at 70°. A precision chosen for one city is a different size in another. And the prefix property fails exactly where it would be most convenient — two points a metre apart can share no prefix at all if a cell boundary runs between them, and the major boundaries sit on the equator and the prime meridian. That is why the eight neighbours are shown here rather than treated as an afterthought: a proximity query that checks only the centre cell will miss points that are closer than ones it finds.