Spatial Inequality Metrics: What They Miss Without Location Data

Picture this: a city with perfect average income but a five-year life-expectancy gap between two neighborhoods a mile apart. That's spatial inequality—and most standard metrics miss it entirely. Without location-aware measures, policies aiming to reduce inequality can accidentally pour resources into areas that already have them, while the truly underserved stay invisible. This guide walks through core spatial inequality metrics, when you need them, how to compute them, and what trips people up.

Who Actually Needs Spatial Inequality Metrics

Urban planners blind to neighborhood effects

You map poverty rates across a city. One district shows 22% — another shows 19%. The gap looks manageable. But you forgot to ask: is the 22% neighborhood surrounded by three others at 35%, or is it isolated between commercial zones and a highway? Without location context, the 19% vs 22% difference tells you nothing about concentrated disadvantage. I have watched planning departments approve zoning changes based on aggregate numbers, only to discover later that a single block group carried all the spillover effects. The spatial Gini will catch this — a simple aspatial Gini won't.

The catch is that even well-meaning planners treat census tracts as independent islands. They aren't. Crime patterns leak across boundaries. School performance follows commuting sheds. A park built in one quadrant lifts property values in adjacent quadrants that never paid for it. That sounds like a fairness problem. It's a measurement problem first.

Public health researchers mapping access

A hospital location study I consulted on ranked neighborhoods by distance to emergency care. Simple enough: draw 5-mile buffers, count facilities. The top-ranked area on paper — a wealthy suburb — actually had no direct road connection because a river split the tract; the nearest bridge was 11 miles away. The dataset said "covered." The residents said "forty-minute detour." This is what spatial inequality metrics catch that tabular rankings miss: topology. Connectivity. The difference between Euclidean distance and real travel time.

“Proximity without topology is just a wish. Access is not a circle on a map — it's a path through streets, schedules, and checkpoints.”

— field note from a Denver public health audit, 2023

Public health researchers who skip spatial weights end up with misleading inequity scores. They report that all census tracts within 10 miles of a clinic have "equal access." But a clinic across a freeway without a pedestrian crossing is, functionally, inaccessible. Moran's I can encode that barrier as a neighbor weight of zero. No location data? You assume the freeway doesn't exist.

Environmental justice advocates tracking pollution

Pollution doesn't respect ZIP code boundaries. Yet most environmental justice screenings compare facility counts per tract — ignoring that a landfill's particulate plume drifts 3 miles downwind. I saw an advocacy group celebrate that their neighborhood had "only two" Superfund sites within its border. Three sites sat just outside the line, 400 feet away. The soil contamination overlapped. The health data overlapped. The metric said no problem existed. Wrong order of analysis — you need a spatial join, not a count within artificial polygons.

The trade-off here is data cost: fine-grained pollution monitoring stations are expensive, and PM2.5 satellite estimates come with their own errors. But running a spatial inequality metric without any location layer is worse. It gives false reassurance. The numbers lie by omission.

Economists studying regional convergence

Regional economists love sigma-convergence: do poor regions catch up to rich ones over time? Run it on state-level GDP per capita and you might conclude inequality is shrinking. Run the same data with a spatial weight matrix — accounting for neighbors' growth rates — and the picture flips. What looks like catch-up is actually spatial spillover: a rich state drags its poor neighbor up, but the gap inside each state widens. The aspatial metric conflates within-region and between-region inequality. That is the kind of misdiagnosis that leads to misplaced policy funding. Most teams skip this: they compute a standard Gini, call it done, and wonder why their development zone plans fail. Location data is not a refinement — it's the difference between seeing a trend and seeing the actual distribution.

Prerequisites: What to Settle Before You Start

Spatial vs. Aspatial Inequality: When Does Location Actually Matter?

You can calculate a Gini coefficient on income data for a city. That number will tell you something. But it won't tell you whether the rich live on one side of the highway and the poor on the other. That's the difference between aspatial inequality — a single summary statistic — and spatial inequality, which cares about where the inequality sits. Most teams skip this distinction. They feed a shapefile into GeoDa, click "Global Moran's I," and get a number that looks plausible. The catch is: if your question is about service access or segregation, an aspatial measure is not just incomplete — it's misleading. Spatial autocorrelation can be high even when a city is economically diverse, simply because poor neighborhoods cluster tightly. The reverse also happens: a metro with extreme income gaps may show low spatial autocorrelation if rich and poor blocks alternate every few streets.

The odd part is that many practitioners default to "spatial = better." Not always. If you're measuring national income inequality for a policy brief, the classic Gini works fine. But if you're deciding where to place a new health clinic, aspatial metrics will lead you wrong. I have seen teams waste weeks computing spatial Gini values for data collected at the state level, only to realize the polygon sizes were too large to show any meaningful clustering. That hurts. Ask yourself first: does proximity between units change the interpretation? If yes, spatial metrics are your tool. If not, you're adding complexity for no gain.

"Spatial inequality metrics answer a different question than standard inequality metrics. Mixing them up is like measuring temperature with a ruler."

— paraphrased from a conversation with a city planning analyst, 2024

Field note: economic plans crack at handoff.

Field note: economic plans crack at handoff.

Data Types: Polygons, Points, and Rasters — Pick the Wrong One and You Lose a Day

Spatial data comes in three main flavors. Polygons (census tracts, counties), points (GPS coordinates of households), and rasters (gridded population estimates). Each demands a different workflow. Polygons are the most common for inequality work because census data lives in them. But polygons have a dirty secret: the Modifiable Areal Unit Problem. Change the boundary shape, change your Moran's I value. I have seen the same dataset shift from "high clustering" to "random" just by switching from census tracts to block groups. The fix is not to avoid polygons — it's to test sensitivity. Run your metric on two different aggregation levels. If the result flips, your conclusion is an artifact of the map, not reality.

Points are cleaner but scarcer. They let you compute nearest-neighbor indices or distance-based spatial weights. The trade-off: you need exact coordinates, which privacy rules often block. Rasters work well for continuous surfaces like poverty probability, but most inequality researchers never touch them. The pragmatic advice: start with polygons, but always check how your results change with a coarser or finer grid. One concrete anecdote: we once ran a spatial Gini on housing value data using ZIP codes. Looked great. Ran it again on census tracts — the cluster pattern reversed. The ZIP code boundaries had merged a wealthy enclave with a poor suburb. Wrong order. We fixed it by rerunning with distance-based weights instead of contiguity.

Software Setup: GeoDa, R, or Python — Pick by What You Will Debug, Not by What You Know

GeoDa is the fastest way to get a spatial Gini or Moran's I on your screen. Click, drag, done. That speed is a trap. The software hides the weighting matrix construction, and when the number is weird, you have no way to inspect the weights. For exploration, fine. For anything you will present to a board or publish, use R or Python — because you will need to debug something.

R's spdep package gives you control. You can inspect the neighbor list, view the weight matrix, and manually run permutations to test significance. The learning curve is worth it the first time your Moran's I comes back as 0.9 and you suspect a weight misspecification. In Python, esda from PySAL does similar work. The trade-off? R has more spatial econometrics libraries; Python integrates more cleanly with machine learning pipelines. Both require you to decide on a weight scheme before you compute: contiguity (rook or queen), k-nearest neighbors, or inverse distance. Each choice changes the result.

What usually breaks first is the coordinate reference system. I have seen people compute distances on unprojected lat/lon data — the numbers look fine but are off by 50% because degrees are not equal-area. Before you run a single metric, confirm your CRS is projected (UTM, State Plane). Then test with a dummy dataset of three known-clustered points. If the output doesn't match your expectation, fix the pipeline before touching real data. Not yet convinced? Run the same metric on random shuffled coordinates. If your tool still reports clustering, something is wrong in the setup.

Core Workflow: Compute a Spatial Gini or Moran's I

Step 1: Build a spatial weights matrix

This is where most workflows either sing or silently fail. A spatial weights matrix — queen contiguity, k-nearest neighbors, or inverse-distance — encodes who is ‘near’ whom. Without it, Moran’s I has nothing to measure. The catch is that choice of weighting scheme is the result. Use queen contiguity on irregular census tracts and isolated rural polygons get zero neighbors — that isn’t sparse data, it’s a structural blind spot. I’ve debugged teams that spent two weeks chasing ‘no spatial autocorrelation’ only to find their matrix had 47% islands. Row-standardize the matrix (each row sums to one) or you’ll weight dense urban clusters double. Wrong order. Fix that first.

Step 2: Calculate the aspatial measure first

Compute a standard Gini coefficient or an ordinary variance before you add the spatial twist. Why? Because the unconditional number sets your baseline — the spatial version is a decomposition, not a replacement. Run ineq::Gini() on income-per-capita across your 200 zones. That single number (say, 0.42) is your anchor. The spatial Gini then partitions that 0.42 into ‘within-neighborhood’ and ‘between-neighborhood’ components. If the aspatial Gini is 0.42 but the between-neighborhood slice is 0.08, your inequality is actually local — block-by-block variation, not regional chasms. That flips policy priorities entirely. Most teams skip this step and then can't explain why their spatial Gini looks almost identical to the aspatial one.

Step 3: Spatial decomposition of inequality

Now you crack the Gini open by spatial groups. Use a decomposition like within-group and between-group components, where groups are defined by the spatial weights clusters or administrative boundaries. The formula is standard: total Gini = within-group component + between-group component + an overlap term. The overlap term is the dirty secret — it captures inequality due to overlapping income distributions across zones, and it can dwarf the other two. I once saw a dataset where between-group inequality was 0.03 but overlap was 0.27; a non-spatial analyst would have declared ‘no regional problem’ while 64% of the inequality was tangled across borders. That hurts. You need all three pieces or the number lies.

Step 4: Global vs. local indicators (LISA)

A global Moran’s I of 0.7 tells you clustering exists. Where it exists? That’s LISA’s job — Local Indicators of Spatial Association. Compute local Moran’s I for each zone, then classify into four quadrants: high-high clusters (hot spots), low-low clusters (cold spots), high-low outliers (isolated rich), low-high outliers (poverty pockets next to wealth). The trade-off is immediate: local Moran’s produces hundreds of p-values. Multiple-testing correction is non-negotiable — use a false discovery rate (FDR) or you’ll map noise as signal. One real-world example: a city health department flagged a ‘high-high’ obesity cluster that turned out to be three adjacent fast-food corridors; local Moran caught what the global index averaged away. That said, LISA is brittle with small counts — fewer than 20 zones per region and the pseudo-p-values collapse. Not yet. You need at least 100 zones for stable local inference.

‘The global number is a summary; the local map is a confession. Look at both or look at nothing.’

— paraphrased from a spatial statistics workshop I attended, 2023

One rhetorical question worth asking: does your audience need a single number for a report, or a map for budget allocation? The global index satisfies the first; the LISA map serves the second. Both are valid — but mixing them up costs you a week of rework. Run the global first, then the local, and always overlay the aspatial baseline. That’s the core workflow. Next, you wire it into actual tools.

Tools, Setup, and Real-World Data

GeoDa: point-and-click for beginners

Start here if you hate command lines. GeoDa loads a shapefile, runs a single menu click, and spits out a Moran scatter plot with LISA clusters colored like a heatmap. The trade-off is brutal, though—GeoDa chokes on anything above 50,000 polygons. I watched a colleague load a block-level dataset for Los Angeles County; the software froze for forty-seven seconds, then crash-dumped with no error log. Fine for classroom demos or a pilot study on twenty census tracts. Not fine for production-grade spatial inequality metrics where you need to iterate thirty model specs before lunch.

Not every economic checklist earns its ink.

Not every economic checklist earns its ink.

R: spdep, sf, tmap for flexible analysis

The spdep package gives you localmoran() and spatial Gini via lorenz(), but the real power is in the data-wrangling chain: sf::st_read() into a simple features object, pipe it through st_join() to attach ACS estimates, then feed the attribute column into spdep::localG() for Getis-Ord star statistics. The catch is projection—you will forget to reproject from EPSG:4326 to an equal-area CRS, and your distance-band weights will silently compute in degrees. That hurts. One failed run cost us two hours debugging why Moran's I went from 0.32 to −0.11 after switching from county to tract polygons. Wrong coordinate system, not wrong data.

Transform your projection before you build a weight matrix. Degrees are not metres. Missing this step is the single most common reason spatial metrics lie.

— field note from a public-health GIS unit

Python: PySAL, geopandas, and matplotlib

PySAL's esda.moran.Moran() handles the heavy lifting—permutation tests, pseudo-p-values, all of it—but the default visualization is hideous. Geopandas fixes that with .plot(figsize=(10,8), column='gini', legend=True), though you lose the significance layer unless you manually assign a color map to the LISA labels. Most teams skip this step and look at raw Moran scatter plots without any cluster map. That's a mistake. The spatial Gini index will look respectably low while a three-block pocket of extreme deprivation remains invisible. I have seen development planners greenlight investment into a region based on a global Gini of 0.22, missing a local hot-spot where child poverty hit 44%.

Data sources: ACS, Eurostat, World Bank

The American Community Survey 5-year estimates remain the gold standard for sub-county inequality in the U.S.—tract-level median household income, Gini coefficient already computed as table B19083. Eurostat provides NUTS-3 Gini values for the EU, but only every three years, and the boundary geometries change after the 2021 revision. World Bank data is coarser—country-level only—and its spatial component is basically non-existent. The odd part is that many practitioners stitch World Bank income tables onto global administrative polygons and call it "spatial inequality mapping." Wrong order. You need geometry and attribute joined before you compute the distance-weight matrix, not after. A colleague in Nairobi tried this with Kenyan ward boundaries and a World Bank decile table—the resulting Moran's I was 0.87, absurdly high, because the underlying income categories had been averaged across wildly different spatial scales. He caught it only when he overlaid the actual survey points and saw the mismatch. Trust nothing that wasn't designed for the polygon level you're using.

Variations for Different Constraints

Small sample sizes: permutation tests and simulation

Your dataset has seven counties. Or twelve neighbourhoods. A spatial Gini computed on that will look precise — but it's a mirage. The odd part is: most textbooks never mention the instability. One outlier shifts the index by 0.15. That hurts. The fix isn't a bigger sample (you can't conjure data). It's permutation testing. You shuffle the spatial labels, recompute the metric a thousand times, and build an empirical distribution of what randomness would produce. If your observed Gini sits outside the 95th percentile of that distribution, you have signal. Otherwise you're measuring noise. I have seen teams skip this and present a 0.62 Moran's I as gospel — only to find the p-value was 0.31.

The trade-off: permutation tests are computationally cheap for small N but they assume exchangeability. That assumption breaks when your regions have wildly different sizes or when spatial autocorrelation is expected under the null. In those cases switch to a conditional permutation scheme or a parametric bootstrap that preserves the global spatial structure. Not perfect — but honest.

Large regions: spatial autocorrelation at scale

Now flip the problem. You have 40,000 census tracts. A full Moran's I requires an N×N weights matrix — that's 1.6 billion entries. Even sparse storage collapses your RAM. The typical response is to sample. Wrong order. Sampling introduces spatial bias unless you use stratified or spatially balanced designs. What works better: tiling. Split the study area into contiguous blocks (say 200×200 cells), compute local Moran's I on each tile in parallel, then aggregate the distribution. You lose the global single-number test but gain a map of where inequality concentrates. That's usually more actionable anyway.

One pitfall: tile boundaries create edge effects — tracts near a seam see artificial neighbours cut off. Overlap your tiles by at least one bandwidth of your distance threshold, then discard boundary estimates before merging. Most teams skip this. The seam blows out your local indicators for 15% of border zones.

'The map looked clean until I overlaid the tile grid — then every seam glowed with false hotspots.' —field engineer debugging a production pipeline

— A sterile processing lead, surgical services

— common complaint on large-scale spatial workflows

Longitudinal data: tracking spatial inequality over time

The hardest variant. You have yearly income data for 150 metropolitan areas across ten years. Running a separate Moran's I for each year gives you a time series of indices — but those indices are not directly comparable. The spatial weights change if administrative boundaries shift (they do). The population distribution changes (it always does). What usually breaks first: a metropolitan area annexes a wealthy suburb in year four; your spatial Gini drops artificially. The fix: use a consistent base geography — typically the earliest year's boundaries — and interpolate later values via area-weighted or population-weighted redistribution.

Even then you face temporal autocorrelation. A Moran's I of 0.45 in year one and 0.52 in year two might be noise, not trend. Permutation tests help again but you need a block bootstrap that resamples entire spatial transects, not individual years independently. Otherwise your confidence intervals are too narrow and you declare trends that don't exist. The concrete next step: build a simple dashboard that plots the index alongside its 90% bootstrap interval for each year. When the intervals overlap across three consecutive years, shut up about the trend. That's not a failure — it's intellectual honesty.

Pitfalls and Debugging: When the Numbers Lie

Edge effects and boundary problems

Spatial data has edges. Always. Administrative boundaries cut through actual patterns—that census tract stops at a river, but the inequality doesn't. I have seen a perfectly respectable Moran's I collapse because someone clipped their dataset to a city limits shapefile without considering the spillover across the line. The edge effect: observations near the border have fewer neighbors, so their local indicators get artificially extreme. One clinic in a low-income block situated right at the county line? The algorithm treats it as isolated when in reality the adjacent high-income suburb across the street doesn't exist in your dataset. Fix it with a buffer zone—clip your study area, then include a 5–10 km ring of surrounding data for neighbor calculations, then drop those buffer observations from final reporting. Another option: use distance-based weights instead of contiguity (rook or queen adjacencies). Contiguity punishes edges; inverse-distance weighting smooths them. That said, distance bands have their own trap—choose too tight a radius and you recreate the problem. Too wide and you wash out local variation. The odd part is this error rarely triggers a warning in R's spdep or PySAL. It just runs and lies quietly.

Not every economic checklist earns its ink.

Not every economic checklist earns its ink.

Modifiable areal unit problem (MAUP)

Same data, different polygons—radically different Gini coefficients. This is not a bug in your code. It's geometry. MAUP hits spatial inequality twice: the scale effect (bigger zones smooth inequality away) and the zoning effect (where you draw boundaries shifts values). I once watched a team run their spatial Gini on census tracts, then on block groups from the same raw data. The tract-level number was 0.32. Block groups? 0.47. Which one is correct? Both. Neither. The catch is you must declare your reporting unit and defend it. Don't compare tract-level inequality from one city with block-group-level from another—you're comparing different statistical fictions. Best practice: run sensitivity checks at two or three aggregation levels. If the rank order of neighborhoods flips when you change polygon size, your conclusions are not robust. That hurts. The MAUP remedy is to report at the finest stable geography available, then explicitly note the scale in every chart footnote. And never—never—choose your unit after peeking at the results.

Stationarity assumptions broken

Global Moran's I assumes one spatial process across your entire map. That works in homogeneous regions. It fails in cities with a freeway splitting rich from poor. Your global index returns something near zero, telling you "no spatial autocorrelation"—yet a local LISA cluster map reveals a hot spot on one side and a cold spot on the other cancelling each other out. The global statistic is not wrong; it's just blind to non-stationarity. The fix: always compute local indicators (Local Moran's Ii or Getis-Ord Gi*) before trusting the global number. If local clusters form a north-south gradient or a doughnut pattern (rich core, poor ring), you have non-stationarity. Report the local map. Abandon the single-number summary. One rhetorical question for your own sanity: Would you trust a national average income to describe the block you live on? No. Same logic applies here.

'The global Moran's I was 0.02. We almost published that as "no spatial inequality." Then we mapped the local clusters and saw a literal line of poverty along the train tracks.'

— field debrief, urban data workshop, 2023

Misinterpreting local vs. global indicators

A high local Moran's Ii doesn't mean that location is "bad." It means that location is more similar to its neighbors than you would expect under randomness—could be a wealthy enclave or a concentrated poverty pocket. Beginners flag every significant local cluster as a problem zone. The opposite might be true: clustering of high-income households signals exclusion, sure, but clustering of mixed incomes (low local Moran) could be genuine integration or just random noise. Read the type of cluster (High-High, Low-Low, High-Low outlier) before you prescribe action. Another pitfall: p-hacking local indicators. Run LISA on 10,000 polygons and you will get roughly 500 "significant" results at alpha = 0.05 by chance alone. Use a multiple-testing correction—Bonferroni is too conservative for spatial data; false discovery rate (FDR) adjustment works better. Most teams skip this. Then they wonder why their intervention zone list changes every update cycle. One concrete fix: set your significance threshold based on the number of expected true clusters from a null permutation simulation. PySAL's esda module does this natively. Use it. Your next step is not another index—it's going back to your raw data and redrawing those buffer boundaries, then re-running with FDR correction, then showing the local map as your primary deliverable. The global number belongs in the appendix. Maybe.

FAQ: Quick Answers to Common Questions

What's the difference between spatial Gini and standard Gini?

The standard Gini coefficient ranks everyone from poorest to richest, sums the gaps, and spits out a number between 0 and 1. It tells you how much inequality exists, but not where it clusters. The spatial Gini does something weird: it re-orders observations by their location, not their income. If rich households sit next to rich households, the spatial Gini stays high—even if the standard Gini would call the region perfectly equal. I once watched a team present a standard Gini of 0.12 (very equal) for a metro area where every rich block was physically adjacent to another rich block. The spatial Gini hit 0.71. That gap matters for transit planning, for school-district funding, for any policy that touches geography. The catch is—the spatial Gini ignores distance decay; it uses adjacency buckets, not road-travel time. Use it when you care about segregation, not when you care about access to a hospital thirty minutes away.

How do I choose the right weights matrix?

Wrong answer: "Use Queen contiguity because the tutorial did." Queen contiguity treats two polygons as neighbors if they share a single point—fine for census blocks in a grid, terrible for Norwegian municipalities separated by a fjord. Rook contiguity demands an actual edge shared. The odd part is—either can fail when a river splits a county. Most teams skip the hard step: build three matrices (Queen, Rook, and k-nearest with k=5), run Moran's I on each, and see if your conclusion wobbles. If one matrix says "strong clustering" and another says "random", you have an edge-effect problem, not a real insight. A blockquote fits here:

'The weights matrix is not a dial; it's a lens. Change the lens, change what you see.'

— paraphrased from a spatial econometrics lecture I sat through

What usually breaks first is islands. Puerto Rico with a k-nearest matrix? It grabs Miami neighbors that are 1,500 miles away—pure noise. Force a distance-decay matrix (inverse distance, with a cutoff threshold) or treat islands as isolated nodes with zero weights. That hurts your degrees of freedom but stops fake spatial correlation.

Can I use these metrics with non-contiguous regions?

Yes—but your interpretation must shift. Moran's I and the spatial Gini don't require touching polygons; they need a defined neighbor relationship. I have seen people run Moran's I on store locations across Canada where Toronto and Vancouver are "neighbors" because they share a postal-code region. That produces a positive I score—but it reflects administrative grouping, not spatial spillover. The pitfall is subtle: non-contiguous regions often introduce your own bias. If you define "neighbors" as "same ZIP code prefix", you might accidentally encode exactly the inequality you're trying to measure. Better approach? Use travel-time bands. Two hospitals in different states but reachable within forty minutes by ambulance? That's real adjacency. Two census tracts that share a ZIP prefix but sit on opposite sides of a mountain range? That's fake proximity. Start with a substantive question—"who can actually walk to this grocery store?"—and let that define contiguity, not the shapefile boundaries.

Next Steps: From Metrics to Action

Visualize Your Results with a Choropleth Map

Numbers in a spreadsheet seduce you into thinking you understand. You don’t. Not until you see the pattern bleed across a map. Open QGIS or even a Python notebook with `geopandas` — load your spatial Gini or Moran’s I output, join it to a polygon shapefile of your study area, and color-code each tract. Darker shades catch your eye first. That cluster of high inequality on the east side? It might be three census blocks with identical indices, but the map shows you why: a rail line, a highway, a zoning wall. The catch is scale — a Moran’s I across the whole city hides neighborhood-level pockets. Zoom in. Always zoom in. I once watched a team spend two weeks polishing a global index that missed a block-by-block segregation pattern visible in thirty seconds on a chloropleth.

Combine with Policy Levers (Zoning, Investment)

A metric without a lever is a museum piece. You computed the spatial Gini — now what? Pull up your city’s zoning map. Overlay it. That high-inequality cluster almost always aligns with an R-1 single-family zone or a historic redlining boundary. The trick is to ask: Can we change the zone here? Not tomorrow, but as a five-year target. Pair the index with investment data — where did the last round of infrastructure dollars land? If your metric shows inequality rising in a tract that received zero capital budget in the past decade, you have a headline, not a footnote. The ugly trade-off: rezoning for density can spike inequality metrics short-term as land values shift. That hurts. But it beats pretending a static map is a solution.

‘We ran Moran’s I, got a 0.72, and everyone nodded. Then we overlaid bus-route frequency and saw the real story — access, not just income.’

— Urban planner, Midwest regional agency (paraphrased from workshop notes)

Write a Brief Report for Decision-Makers

Your audience doesn't care about p-values. They care about where to put the next community center or which block group to target for a housing voucher pilot. Write the report in three moves: (1) one page — single map, three bullet findings, one recommended action. (2) Appendix with your methods — keep it two paragraphs, no equations. (3) A one-sentence punch line: “Rezoning tracts 27 and 33 to mixed-use could reduce the spatial Gini by 0.08 in five years.” That's specific. That's testable. Most teams skip this step — they dump a Jupyter notebook on a city council member and wonder why nothing changes. Wrong order. Deliver the decision, not the computation. The metric was the tool; the action is the output.