Gravity Rewired: From Huff’s 1960s Trade Areas to a Pythonic Spatial Intelligence Stack

Location decisions are rarely about location alone.

A supermarket does not win customers simply because it is nearby. A hospital does not serve a population just because it sits inside a neat administrative boundary. An airport does not own a catchment area because someone drew a circle around it in a slide deck, though many slide decks have committed worse crimes.

Real market areas are probabilistic. They are shaped by attraction, distance, travel time, alternatives, service capacity, and the stubborn fact that people do not behave like geometry homework.

That is why Thomas Wieland’s huff Python package is more interesting than its modest software-paper packaging suggests.¹ The paper is not proposing a new theory of spatial interaction. It is doing something more operationally useful: it turns a family of classic market-area models — especially the Huff model and Multiplicative Competitive Interaction model — into an end-to-end, open-source Python workflow.

The contribution is not “here is another package.” The contribution is that market-area analysis has finally been assembled as a coherent stack: data import, origin-destination matrices, travel-time or distance calculation, probability estimation, customer-flow prediction, empirical calibration, accessibility analysis, and map visualization.

That matters because market-area analysis often fails in practice not at the level of theory, but at the level of plumbing. The model may be elegant. The workflow is often a swamp.

The real mechanism is not radius; it is competitive allocation

The most common misunderstanding of market-area analysis is to treat it as catchment mapping: draw a radius, count the people inside it, call it a market. This is easy, visual, and often wrong.

The Huff model begins from a more useful premise. A customer origin can be exposed to multiple supply locations at the same time. Each location has some attractiveness. Each origin-location pair has some travel cost. The model estimates the probability that demand from origin $i$ goes to location $j$.

In the paper’s mathematical appendix, the basic Huff utility is expressed as:

where $A_j$ is the attraction or size of supply location $j$, $t_{ij}$ is travel time from origin $i$ to location $j$, and $\gamma$ and $\lambda$ are weighting parameters. This utility is then converted into a probability:

Expected flow follows directly:

where $C_i$ is the customer or expenditure potential at origin $i$.

This is the central mental shift: a market area is not a fixed polygon. It is an allocation of demand under competition.

A store can receive 40% of one neighborhood, 15% of another, and almost nothing from a third. A clinic can be geographically close but functionally unattractive if capacity, specialization, or travel friction makes another provider more plausible. A transport node can draw users across jurisdictional boundaries because actual movement ignores administrative tidiness. Bureaucracy draws borders; customers draw flows.

The old gravity logic is simple enough to explain. The hard part is making it usable without turning every project into a GIS-export ritual.

Why this package exists: three frictions that kept the model trapped

The paper identifies three practical frictions in market-area modeling. They are not glamorous, but they are exactly the kind of friction that decides whether a model becomes an operational tool or remains a methodological ornament.

This is where huff becomes useful. The package does not merely calculate a Huff probability once the analyst has already solved everything else. It attempts to cover the full workflow.

Users can load customer origins and supply locations from point shapefiles, CSV, or XLSX files. They can define attributes and weightings for origins and destinations. They can create an interaction matrix containing all possible origin-destination combinations. They can calculate distances or travel times inside that workflow. Then they can estimate probabilities, flows, and total market areas.

For a basic analysis, that sequence is already enough. For a serious analysis, the important addition is calibration.

Calibration is where market maps become models

A radius map asks: who is nearby?

A calibrated market-area model asks: how strongly does nearness actually matter here?

That difference is not cosmetic. In grocery retail, travel-time sensitivity may be steep because people buy frequently and prefer convenience. In specialized healthcare, patients may tolerate longer travel if the service is scarce or high-value. In airport catchment modeling, travelers may weigh travel time against flight availability, ticket prices, and connection options. The same kilometer does not mean the same thing across domains.

The paper’s package supports parameter estimation from empirical data in several forms: customer flows, regional market shares, or total sales. It includes the econometric MCI approach when regional market shares are available, and Maximum Likelihood optimization when the analyst works with regional market shares, customer flows, or total market areas.

This is not a decorative feature. It is the difference between assumed behavior and observed behavior.

The MCI model generalizes the idea by allowing multiple supplier characteristics. Instead of only asking whether a location is large and close, the model can incorporate several attributes:

Here, $A_{hj}$ is the $h$-th characteristic of supplier $j$, and $\gamma_h$ is the corresponding coefficient. The log-centering transformation then makes estimation more tractable under suitable data conditions.

For business readers, the point is straightforward: calibration turns a spatial model from a pretty allocation machine into a decision instrument. It lets the analyst estimate how much distance, size, capacity, or other location attributes actually matter in a given setting.

The boundary is equally important. Calibration is only as useful as the empirical data behind it. If observed flows are noisy, biased, stale, or unavailable, the model may still be useful for scenario comparison, but not for confident forecasting. The package provides tools; it does not summon trustworthy data from the void. Convenient, perhaps, but apparently Python has limits.

The package architecture mirrors the spatial market

The paper describes huff as modular and object-oriented. That phrase can sound like routine software brochure language, but here it is analytically meaningful.

The class structure follows the conceptual actors of a spatial market:

The interaction matrix is the hinge. It connects origins to destinations and stores the pairwise information needed for modeling: travel times, distances, and attributes. From that matrix, the analyst can call methods for transport costs, probabilities, flows, market areas, and MCI fitting.

This matters because market-area analysis is easy to fragment. One tool calculates travel time. Another stores geospatial attributes. A spreadsheet holds sales data. A script estimates parameters. A GIS project renders the map. Every export/import step creates opportunities for broken joins, inconsistent identifiers, stale files, and silent analytical drift.

A unified object structure does not guarantee truth. But it reduces the number of places where truth can be accidentally dropped.

The paper is a workflow contribution, not a benchmark paper

The evidence in this paper should be read correctly. It is a software paper, not an empirical performance study.

There are no ablation tables showing that one algorithm beats another by a fixed percentage. There are no benchmark datasets where huff outperforms competitors on predictive accuracy. That is not the paper’s purpose.

The support comes from four different types of evidence:

That distinction is important. The article should not sell huff as “more accurate” than proprietary GIS software or specialized R packages. The paper does not show that. The stronger and better-supported claim is that huff provides an open Python workflow that integrates pieces previously scattered across tools.

In business terms, the value is workflow consolidation and reproducibility, not magical spatial clairvoyance.

Accessibility analysis broadens the use case beyond retail

The package also includes accessibility methods: Hansen accessibility and Two-Step Floating Catchment Area analysis, usually abbreviated 2SFCA. This is where the paper moves beyond classic retail site selection.

Hansen accessibility measures weighted access from an origin to opportunities at multiple locations:

where $O_j$ represents opportunities at location $j$, and $d_{ij}$ is distance or travel time. In plain terms, accessibility is not just whether a facility exists. It is whether meaningful opportunities are reachable under a distance or travel-time decay logic.

2SFCA adds another layer by incorporating supply-demand ratios. First, it computes the supply-to-demand ratio around each supply location. Then it aggregates accessible supply for each origin within a catchment threshold.

That is especially relevant for healthcare. A hospital catchment is not just a “service radius.” It depends on population distribution, travel friction, facility capacity, and competition among providers. The paper notes that huff is being used in a health geography project at Wuerzburg university hospital dealing with catchment areas of pediatric oncology care. That is a telling example because specialized care is precisely where radius-based thinking becomes crude.

A nearby facility with limited capability may be less relevant than a farther specialized one. A large facility may attract demand across wider geographies. A rural population may be technically “covered” on paper and practically underserved in travel-time reality.

This is why the package’s bridge between retail market-share modeling and healthcare accessibility is more than domain expansion. It reveals the shared mechanism: spatial service systems allocate demand under friction and capacity constraints.

The business pathway: from map to scenario engine

For a company or public-service planner, the practical path looks like this:

The most obvious business use case is retail network planning. A company considering a new store can model how demand may shift from existing locations, estimate cannibalization, and compare scenarios under different distance-decay assumptions. The model will not know whether the new store smells like fresh bread or despair, but it can structure the spatial competition question.

A second use case is service capacity planning. Clinics, hospitals, schools, and public offices often face the same core problem: where are users likely to go, how far must they travel, and where does supply fail to match demand?

A third use case is competitive intelligence. If a rival opens a new location, a calibrated model can estimate which existing sites are most exposed. This is more disciplined than circling a competitor on a map and making confident noises in a meeting.

A fourth use case is investment screening. Location-heavy businesses — retail chains, logistics services, healthcare providers, leisure facilities — can use market-area models as a first-pass analytical layer before expensive field research.

The inference from Cognaptus is that huff can serve as a lightweight spatial-decision backend in broader analytical systems: dashboards, site-selection tools, planning simulators, and agentic workflows that generate scenarios and explain trade-offs. The paper itself does not build such business applications. It supplies a modeling layer that could support them.

Why Python matters here

Spatial interaction modeling has often lived in GIS software, regional science toolkits, or R packages. That is not a problem by itself. R is excellent for statistical modeling, and GIS tools remain essential for many spatial workflows.

The paper’s specific claim is narrower: no open-source Python package currently provides market-area analysis and parameter estimation for the Huff or MCI model, and no open-source software package covers the whole workflow described in the statement of need. The paper contrasts this with R packages that cover parts of the workflow and proprietary GIS software that covers nearly the complete workflow in a closed environment.

The Python positioning matters because many modern analytical teams already use Python for data engineering, dashboards, optimization, machine learning, and automation. If market-area analysis can live in the same environment, it becomes easier to connect spatial demand modeling with:

• sales forecasting;
• customer segmentation;
• route and travel-time APIs;
• facility-location optimization;
• public-service dashboards;
• simulation agents;
• reporting pipelines.

This is the quiet infrastructure story. The model becomes less of a specialist artifact and more of a composable component.

That composability is more important than fashion. Python does not improve the Huff model because it is Python. Python improves adoption when it reduces switching costs and lets spatial interaction modeling sit inside existing data workflows.

The limits: calibration, assumptions, and the danger of elegant maps

The paper is careful enough that the main limitations are visible from the workflow itself.

First, model outputs depend strongly on weighting schemes. Different distance-decay functions can lead to different conclusions. That is not a nuisance parameter; it is often the decision. If a model says a facility has a wide catchment only because the analyst chose a gentle decay curve, the result is not insight. It is curve-shaped optimism.

Second, empirical calibration requires empirical data. The package supports calibration using regional market shares, customer flows, or total sales, but those inputs may be unavailable or imperfect. In public-service contexts, observed flows may reflect constrained access rather than true preference. In retail, sales data may mix location effects with pricing, assortment, promotions, branding, and local management quality. Location models can absorb these effects unless the analyst handles them carefully.

Third, travel time is not always stable. Congestion, public transport schedules, road quality, weather, and temporal service availability can affect real accessibility. A static travel-time matrix may be useful, but it is still a simplification.

Fourth, the paper is not an empirical validation of every use case. It presents package functionality, architecture, mathematical foundations, and field positioning. It does not demonstrate predictive accuracy across retail, healthcare, airports, and recreation facilities in one comparative benchmark.

These boundaries do not weaken the package. They define how it should be used. A good spatial model is not a replacement for business judgment. It is a way to stop business judgment from floating freely above geography.

What this changes for Cognaptus readers

The useful lesson is not “download this package.” That may be the next step for analysts, but not the main strategic point.

The deeper point is that spatial decision-making is becoming more reproducible, programmable, and composable. Models that once required proprietary GIS environments or fragmented workflows can now be embedded into open analytical stacks. That changes who can run the analysis, how often it can be updated, and how easily it can be connected to scenario planning.

For business teams, this means location strategy can move from static reports to living models. A retail network can update demand allocation as new stores open. A healthcare planner can test future supply scenarios. A public agency can compare accessibility under different facility investments. A real-estate team can treat trade-area estimates as an input into financial models rather than as a map pasted into an appendix.

For AI and automation teams, the package points to a more grounded form of “spatial intelligence.” Not the vague kind where an agent says a location “looks promising.” The useful kind where an agent can call a model, test assumptions, compare decay functions, explain sensitivity, and output a scenario table with actual spatial logic behind it.

That is less glamorous than a black-box AI oracle. It is also less likely to embarrass everyone involved.

Old gravity, new workflow

The Huff model has been around since the 1960s because the basic intuition remains powerful: people allocate demand across competing locations according to attraction and friction. The theory is old. The workflow problem is not.

huff matters because it packages that theory into an open Python workflow that covers the practical sequence analysts actually need: origin-destination data, transport cost, probabilistic allocation, empirical calibration, accessibility analysis, and visualization.

It does not reinvent gravity. It rewires it.

And for location-heavy decisions, that may be exactly the point. The future of spatial intelligence will not be built only from larger AI models. It will also be built from transparent, calibratable, domain-specific tools that know what kind of problem they are solving.

Gravity still pulls. Now it has a Python stack.

Cognaptus: Automate the Present, Incubate the Future.