#📝 Note: Geo-Hashing
#Overview
Geohash encodes a (latitude, longitude) pair into a short alphanumeric string. Strings sharing a common prefix occupy the same geographic region — enabling efficient proximity queries via simple string prefix matching.
#Core Idea
- Hierarchical Cells: The world is divided recursively into 32 cells at each level. A 1-char geohash = one of 32 large cells; 6-char = ~1 km² cell; 9-char = ~5 m² cell.
- Proximity via Prefix: Two points in the same geohash cell share the full prefix. Nearby points in adjacent cells share a shorter prefix.
- Neighbor Lookup: Every geohash cell has 8 neighbors. For a proximity search, query the target cell + all 8 neighbors to avoid boundary misses.
- Precision Levels:
| Length | Cell Width | Cell Height |
|---|---|---|
| 4 | ~39 km | ~20 km |
| 5 | ~5 km | ~5 km |
| 6 | ~1.2 km | ~0.6 km |
| 7 | ~153 m | ~153 m |
| 8 | ~38 m | ~19 m |
#When to Use
- Proximity matching where location data is frequently updated (cache by geohash cell).
- Partitioning data geographically in NoSQL stores (use geohash as partition key prefix).
- Generating candidate sets for nearby entities before applying precise Haversine filtering.
#When NOT to Use
- When queries span large areas (multi-hundred km) — S2 cells handle sphere-level geometry better.
- When sub-meter precision is required — use PostGIS with full geometry types.
#Trade-offs
- Pros: Simple string operations; easily cached; works in any key-value store; neighbor enumeration is O(1).
- Cons: Edge-case boundary issue (adjacent points may differ in prefix at cell edges); not equal-area cells (cells are larger near equator, smaller near poles).
#Used In This Repo
- Tinder Feed (#26) — 6-char geohash cells used to bucket users for candidate generation