Geohash Overview

What Geohash is

Geohash is a discrete global grid system that encodes a lat/lng rectangle as a base-32 string. It works directly in unprojected latitude/longitude degrees — no icosahedron, cube, or dodecahedron projection is involved the way there is for H3 or S2 — which is both its simplicity and the source of its most severe geometric limitation (non-equal-area cells that shrink sharply toward the poles, described below). Geohash is documented here on the same generic terms as the other systems; see cell-system-comparison for the full matrix.

Construction: recursive bisection, base-32 encoding

A geohash is built by recursively bisecting a starting bounding box (the whole lat/lng extent) in half, alternating which axis is bisected — longitude first, then latitude, then longitude again — and appending a bit for which half the target point falls in (0 for the lower half, 1 for the upper half). Every 5 bits accumulated this way are encoded as one base-32 character. Because each character encodes 5 bits and the axis alternates every bit (not every character), each additional character subdivides the current rectangle into 32 pieces arranged as an 8-wide by 4-tall grid where longitude got the extra bit, or 4-wide by 8-tall where latitude did — the two patterns alternate by string position. The net effect: each character subdivides the parent rectangle into 32 children, none of which is a hexagon, spherical quadrilateral, or pentagon — simply a smaller lat/lng rectangle in degrees.

Hierarchy: exact prefix containment

Geohash's hierarchy relationship is a string-prefix relationship, and it is exact: every point inside a geohash of length N falls inside every shorter geohash that is a prefix of it, with no exception, because the subdivision is a literal recursive bisection of the bounding rectangle — no approximation or index-arithmetic step analogous to H3's aperture-7 logic. Geohash's containment guarantee is as strong as S2's exact quad tiling, though the two arrive at exact containment by different constructions (recursive bisection vs. an exact quad tree of spherical quadrilaterals), and Geohash's hierarchy factor is 32 children per parent rather than 4 (S2) or approximately 7 (H3).

Lengths and non-equal-area cells

Geohash strings in common use range from 1 to 12 characters. Because the subdivision is performed directly in latitude/longitude degrees rather than on a projected or equal-area surface, a geohash rectangle's true ground area at a fixed string length is not constant: a degree of longitude covers less ground distance as latitude increases toward the poles (proportional to the cosine of latitude), so geohash cells of the same length shrink toward the poles and are widest at the equator — a more severe, more geometrically obvious area variance than H3's (roughly 2x, icosahedron projection) or S2's (cube projection). A geohash near a pole can be a small fraction of the ground area of an equatorial geohash of the same length, with no correction applied by the encoding itself.

Core operations

Point indexing

Encoding a lat/lng point to a geohash string of a given length is the direct output of the recursive-bisection encoding process itself — there is no separate lookup step the way H3's `latLngToCell` walks an icosahedron hierarchy.

Boundary extraction

A geohash string decodes directly to its bounding rectangle (min/max lat, min/max lng) — the Geohash equivalent of `cellToBoundary`, and exact by construction since the rectangle *is* the encoding.

Centroid extraction

The rectangle's midpoint is the conventional decoded 'center' of a geohash, analogous to `cellToLatLng`.

Polygon fill

Geohash has no native polygon-fill primitive analogous to H3's `polygonToCells` or S2's `S2RegionCoverer`. Coverage is approximated by enumerating candidate prefixes over a polygon's bounding box and testing each candidate rectangle for intersection with the target polygon, discarding non-intersecting prefixes — an approximate, hand-rolled equivalent, not a built-in system capability.

Compaction

Geohash has no built-in compaction operation comparable to H3's `compactCells` or S2's cell-ID range collapsing. A caller wanting to collapse 32 sibling prefixes into their common parent prefix must implement that check manually against the full sibling set.

Use cases: prefix bucketing and key-range scans

Geohash's practical advantage is operational simplicity: a geohash string sorts and range-scans naturally in any ordinary string-keyed index (a database B-tree, a key-value store, a URL path segment), and truncating a string to a shorter prefix is itself the exact coarsening operation — no separate "get parent cell" call is needed. This makes Geohash reasonable for simple proximity bucketing or key-range scans where polar area distortion and the lack of native polygon fill are acceptable trade-offs, but a poor choice wherever precise polygon coverage or robust near-boundary proximity matching is required — those are better served by H3 or S2.

What must not be assumed

Do not assume Geohash cells are equal-area — the polar shrinkage is severe and unlike either H3's or S2's projection-driven variance. Do not assume Geohash supports native polygon fill or compaction — both must be hand-built from the prefix/rectangle primitives. Do assume prefix containment is exact, and do assume string proximity is not a reliable proxy for spatial proximity near bisection boundaries.

References

• Geohash — Wikipedia: Geohash (last verified 2026-07-22)

Assumptions and limitations

This page describes Geohash's generic capability model as registered in data/cell-systems.yaml. Specific base-32 alphabet choice, exact bit-per-character packing, and any platform-specific length convention should be verified against the geohash implementation in use before being relied on for a production calculation.

Illustration — a real geohash cell