Beyond the Radius: Why I’m Switching Dealer Networks to Hexagonal Grids

In my time as a Senior Solution Architect, I’ve seen dozens of "Store Locator" implementations. Most of them follow the same tired pattern: a user enters a zip code, the backend runs a basic radius search or a Point-in-Polygon (PiP) check against city boundaries, and a list of pins drops on a map.

It works for a small scale. But when you’re managing a rapidly expanding network—like a national EV dealer footprint—the "standard" way starts to break.

As I transition deeper into Data Engineering, I’ve realized that the secret to a performant, scalable dealer directory isn't better SQL queries; it's better spatial indexing. Here’s why I’m moving away from traditional boundaries and leaning into Hexagonal Grids (H3).

The Problem with Administrative Boundaries

Traditional Point-in-Polygon checks rely on administrative shapes (districts, cities, or zip codes). These shapes are "noisy." They are irregular, vary wildly in size, and—most importantly—they carry geographic bias.

If a customer lives 1km away from a dealer but across a "city line," a standard PiP query might exclude that dealer entirely. To fix this, we usually add complex buffer logic, which kills performance as the dataset grows.

Enter the Hexagon: Why H3?

For a recent project involving localized dealer pages, I started implementing Uber’s H3 spatial index. Unlike square grids (which have different distances to neighbors vs. diagonals), hexagons are isotropic. Every neighbor is the same distance away.

The Engineering Advantage

1. Uniformity: Every cell is the same shape and size. This allows for "apples-to-apples" density analysis across different cities.
2. No More Heavy Joins: Instead of running a heavy ST_Intersects on a complex polygon, you convert a coordinate to an H3 index (a simple 64-bit integer).
3. Point-in-Polygon at Scale: Finding which dealers are in a "region" becomes a simple integer comparison. In my experience, this can be 10x to 50x faster than traditional geospatial joins in a standard Postgres/PostGIS setup.

Real-World Application: The Dealer "Heat Map"

In a recent implementation, we didn't just want to show where dealers are; we wanted to show where they should be.

By bucketing lead data into H3 cells and overlaying them with existing dealer cells, we created a "gap analysis" tool. Because hexagons tile perfectly without gaps, we could visualize demand clusters that were previously hidden by the awkward shapes of city zip codes.

Is Point-in-Polygon Dead?

Not entirely. If you need to know exactly if a store is within the legal tax boundary of Gurugram, you still need PiP. But for discovery, search, and data visualization, it’s overkill and under-performant.

As I build out more data pipelines using Airflow and Spark, the goal is to pre-calculate these H3 indexes at the ingestion layer. By the time the data hits the frontend (React/Next.js), the "geospatial" work is already done. It’s just a lookup.

The Wrap Up

Moving from "maps as an image" to "maps as a data structure" is the hallmark of a modern Data Engineer. If you’re still struggling with slow store locators or biased geographic reporting, it’s time to stop thinking in circles and start thinking in hexagons.