The closest driver is invisible to the index
A hypothetical dispatch service cannot find the closest driver. The rider and driver are ten meters apart, on opposite sides of a spatial cell boundary. The service queried only the rider's cell.
The index returned exactly the region you asked for. That region was not the circle you meant.
Separate candidate coverage from exact distance
Geohash recursively partitions latitude and longitude and interleaves their bits into a prefix. Close prefixes describe nearby cells, but nearby points can lie across boundaries with very different prefixes. A query must cover every cell intersecting the search region, then filter candidates using the required distance model.
Is āalways query the center and eight neighborsā correct for every radius and latitude?
For a sphere, with angles in radians:
Clamp numerical roundoff in to the valid interval. Haversine gives great-circle distance under a spherical model; precise ellipsoidal requirements need an appropriate geodesic method. Driving time also depends on roads and traffic, not just distance.
Choose the partition geometry
A quadtree adapts subdivisions to point density but moving objects can create update and synchronization work. S2 projects the sphere through cube faces and orders hierarchical cells with a Hilbert curve. H3 uses a hierarchical hexagonal grid with pentagonal exceptions and spherical distortion. It is useful for neighborhood aggregation, but neither all cells nor all neighbor distances are perfectly identical.
| Workload | Useful design question |
|---|---|
| Nearby static venues | Can a spatial database index and exact filter answer directly? |
| Rapidly moving drivers | What update rate and location age must the serving index tolerate? |
| Regional aggregation | Which cell hierarchy gives stable grouping at the desired resolution? |
| Exact route ETA | Which candidate filter precedes the road-network calculation? |
A spatial database's GiST/R-tree-style index may already solve the query. Do not build a distributed cell directory merely because the coordinates are two-dimensional.
The planet has a seam, and the data has an age
A longitude interval crossing +180/-180 cannot be represented as ordinary BETWEEN 179 AND -179. Split it into wrapped intervals or use a library that understands the region. Test polar areas, boundaries, large radii, duplicate cell coverage, and dense cities.
A driver's old position can be geometrically perfect and operationally useless. Store observation time, sequence/version, and expiration policy. Ignore out-of-order location updates; remove stale candidates. An in-memory serving index plus durable location stream can separate freshness from history, but choose flush/retention intervals from actual requirements, not a universal recipe.
Estimate memory from sampled member sizes and index overhead. Measure candidate amplification: how many points are fetched versus returned? Finer cells reduce irrelevant candidates but increase covering and metadata work. Dense hot cells may require another partitioning dimension.
Mental model: the spatial index produces a complete candidate cover; exact geometry and freshness decide which candidates are usable.
Transfer: the nearest available driver
The geometric nearest neighbor is busy. The next nine are stale. Would fetching exactly ten nearest positions before availability filtering guarantee a match when one exists?
Source trail: 11-geospatial-geohash-quadtree-s2. See the source map for consolidation and reference-retained material.