Trade areas, now derived from how workers actually move

For most of Axiom Locus''s existence, "trade area" has been a placeholder. The product page promised it. The scoring methodology referenced it. But the actual polygons under the hood were one of two things: a fixed-radius buffer around a centroid, or a network-time isochrone (driving + walking) that assumed everyone''s day looks like a delivery van.

Both of those approximations are wrong in the same way. A neighborhood''s trade area isn''t a circle, and it isn''t a 15-minute drive-time bubble. It''s the set of places where the people who live, work, and spend in that neighborhood actually go — and that pattern bears almost no resemblance to a smooth shape on a map.

As of this week, every H3 cell in Locus has a real trade area, fit to observed worker flows. Here''s how it works and why it matters.

What changed

We''ve integrated the U.S. Census Bureau''s LEHD LODES dataset — Longitudinal Employer-Household Dynamics, Origin-Destination Employment Statistics — and fit a gravity model over the worker flows it contains. The output is a per-cell trade-area polygon that reflects where workers from that cell actually commute to, and where workers in nearby cells commute from. The polygons are stored in cell_trade_areas and exposed in the new TradeAreaPanel on every cell page.

LEHD is one of those underrated public datasets. It''s the residual product of the unemployment insurance system: every state reports, for every job, the census block where the worker lives and the census block where the job is. When you aggregate that across the whole country, you get a directed graph of how the U.S. labor force moves on a typical weekday, at block resolution. There''s a ~2-year lag and the lowest geography unit is suppressed for privacy, but for anything bigger than a single building, the signal is excellent.

We''re not the first to use LEHD for retail or CRE analytics. Most people who pull it use it as a feature — average commute distance, daytime population multiplier, workforce density by sector. That''s fine, but it leaves the spatial information on the table. The block-to-block flow matrix is what makes LEHD different from any other commute dataset, and a gravity model is the natural way to fit it.

What''s a gravity model, briefly

The form is older than gravity itself in this context — Newton''s law of gravitation, repurposed for human movement by Stewart in the 1940s, then extended by Wilson in the 70s and beaten to death by transportation engineers ever since.

The intuition: flow between two places is proportional to the "mass" of each place (population, jobs, retail floorspace — pick your metric) and inversely proportional to some power of the distance between them. The model has two parameters: the mass exponents and the distance decay. Fit those two against observed flows and you get a generative model that tells you, for any pair of cells, the expected flow between them — even pairs that didn''t appear in the training data because both were suppressed.

We fit ours with scikit-mobility, an open-source Python library that''s quietly become the standard for this work. The training data is LEHD''s annual O-D matrix for every state. The distance metric is great-circle on H3 cell centroids. We re-fit nationally each year when new LEHD vintages drop, and we keep the per-state parameters because commute decay varies a lot — a New York cell''s trade area looks completely different from a Houston cell''s, even at the same density.

Why polygons instead of just flow scores

A few reasons.

First, polygons are easier to reason about than matrices. An analyst evaluating a site doesn''t want to think in 50,000-by-50,000 cell pairs; they want to see a shape and trust that the shape captures the right places. The gravity model gives us a clean way to threshold — keep cells until cumulative outflow probability hits some target like 0.85, draw the convex hull around them, and the resulting polygon is interpretable.

Second, polygons compose. Once you have a trade area for cell A and a trade area for cell B, you can ask spatial questions: do they overlap? Does the overlap correspond to a contested retail corridor? Does adding cell A''s trade area to cell B''s substantially change the union? Those are the questions retail and CRE analysts actually ask, and they don''t reduce to a flow score.

Third — and this is the part we care about most — polygons let us back-derive cell-level features for scoring. Every Locus cell now gets a "trade area population," "trade area jobs," "trade area daytime population," computed by summing whatever underlying signal you care about across the cells inside the trade-area polygon, weighted by the gravity model''s probability mass. That''s the right denominator for a lot of questions. "Building permits per resident" is fine; "building permits per commute-shed resident" is sometimes a much better signal.

The honest caveats

Two caveats.

LEHD lags. We''re typically working with data that''s two years behind real-time. For trade areas that''s usually fine — commute patterns don''t shift that fast — but for cells that have seen rapid change (a new transit line, a major employer move-in or move-out), the polygon may not yet reflect the current ground truth. We''re cross-checking with mobile-device data for the cells where the shifts are largest, but the LEHD-anchored polygon is the canonical one.

Suppression matters. LEHD suppresses cells with very few observations, which means rural and very-low-density areas have noisier polygons. We backfill the suppressed cells using the gravity model''s predictions, which is honest as long as you remember that the prediction is doing more work in those areas than in dense cells where the observed flows do the heavy lifting.

Where to look

Every cell page now has a "Trade Area" tab below the score breakdown. The polygon is rendered on the map, the H3 cells inside it are listed with their probability weights, and a small table summarizes the trade area''s aggregate stats: population, jobs, median income, daytime population.

For practitioners: the underlying polygons are queryable via the cells API, and the gravity model parameters per state are exposed via the methodology endpoint. If you''ve been using a third-party trade-area product and want to A/B compare against this one, it''s quick to do.

We''ll iterate on the model — there are obvious refinements around mode-of-transit weighting, and we want to bring in journey-to-work data from the ACS for sanity-checking — but the baseline is live as of today on every metro Locus scores. No fixed-radius placeholders left.