>>192602, >>192604, >>192605, >>192606, >>192607, >>192608, >>192609, >>192610, >>192611, >>192612, >>192613, >>192614, >>192615, >>192616, >>192617, >>192618, >>192619, >>192620, >>192621, >>192622, >>192623
Here is how we completely bypass that bottleneck:
1/ The 1D Hilbert Curve Trick
Instead of bounding boxes, we project the Earth onto a cube, dividing it hierarchically into a quadtree of tiles. We order these tiles along a 1D Hilbert space-filling curve.
Because this curve is a self-similar fractal, physical proximity is mathematically preserved as consecutive 64-bit integers. A complex 2D region is instantly flattened into contiguous 1D integer ranges [range_min, range_max].
2/ "Tile-Unions" over Bounding Boxes
To index a jagged Census Tract boundary, we tile it using a "tile-union." We cover the massive, solid interior with large, coarse parent tiles, and trace the jagged edges with tiny, highly refined micro-tiles.
Because of our quadtree's parent-child prefix invariant, these multi-resolution tiles live in the exact same index table. Our entire global administrative boundary map takes up barely 46 MB!
3/ The Under-5ms Range Join
Finding containment is reduced to a single, lightning-fast database range check: point_id BETWEEN range_min AND range_max
No heavy spatial indexes or R-Tree traversals. Just basic integer comparison.
4/ The "Interior vs. Boundary" Fast Path
We tag every tile in our index:
INTERIOR: If a point's integer ID falls within an interior tile range, containment is mathematically guaranteed. We skip geometry checks entirely. No PostGIS, no Shapely, instant resolve.
BOUNDARY: Only when a point lands on a jagged edge tile do we trigger a highly localized, micro-geometric check.
5/ Why Hexagons Fail Here
Why not use hexagonal grids? Hexagons don't nest. Their parent-child boundaries spill over, and their IDs across scales live in disjoint integer spaces.