// the find
uber/h3
Hexagonal hierarchical geospatial indexing system
H3 is Uber's hexagonal grid system for partitioning the Earth's surface into cells at 16 resolution levels. It's a C library with bindings for most major languages, and it's the right tool when you need to aggregate, cluster, or join geospatial data without the distortion you get from lat/lng bounding boxes or square grids. If you're building ride-sharing dispatch, delivery zone management, or any kind of geographic density analysis, this is the standard.
The hierarchical design is the core win: a resolution-10 cell is always a child of its resolution-9 parent, so you can aggregate up and down the tree without re-indexing. The polygon-to-cells fill (polyfill) is fast and the compaction algorithm reduces cell count dramatically for large areas. The test suite is thorough — exhaustive tests, fuzz targets with OSS-Fuzz integration, benchmark targets, and Valgrind support all in one CMake build. Bindings for Java, Python, and JavaScript are maintained by Uber alongside the C core, so you're not stuck linking C yourself.
12 of the 122 resolution-0 cells are pentagons, not hexagons, because you can't tile a sphere perfectly with hexagons — this is a mathematical inevitability but it creates real edge cases in neighbor traversal and polygon fill that you have to explicitly handle or your code silently produces wrong results near those cells. The C API uses error codes through output-pointer parameters (`H3Error` return with the actual value written to a pointer), which is fine for C but produces awkward wrapper code in higher-level language bindings. There's no built-in persistence or indexing layer — H3 gives you the cell IDs and you're on your own for storing and querying them efficiently, which usually means adding a Postgres extension or DuckDB spatial. Documentation is good but the website examples lag behind the v4 API rename (functions like `h3ToGeo` became `cellToLatLng`) and you'll hit stale StackOverflow answers constantly.