When geospatial analysis helps

Someone asks for “a map of our customers.” You could spend a week geocoding addresses, picking a basemap, and shipping a glowing dot density that looks like a keynote. Then the decision meeting is about whether to open a second warehouse in the same metro you already serve, and the map never answered travel time, capacity, or overlap. Pretty is not the same as useful. Geospatial work earns its keep when place changes the choice.

This is Part 1 of Geospatial for beginners, a short series for analysts who can join tables and build dashboards but have not yet decided when latitude and longitude are worth the mess. Part 2 will cover map design honesty. This part is the filter: when geo helps, when it wastes time, and what to write down before you open a GIS tool.

What you’ll learn

A simple test for whether location belongs in the analysis
Good-fit patterns: catchment, delivery radius, store coverage, and similar ops questions
Weak-fit patterns: tiny samples by hex, privacy risk, and maps as decoration
Core ideas: unit of analysis, join keys, coordinate sanity, and aggregation
A project card and worked store-coverage example you can reuse

The decision test for geo

Ask this before you geocode anything: If two rows had the same attributes but different locations, would the recommended action change? If yes, space is part of the model. If no, a bar chart by region name might be enough, and a full spatial stack is optional flair.

Examples where the answer is usually yes:

Which store should fulfill this order given drive time and inventory?
Where do service calls cluster relative to technician home bases?
Does our retail coverage leave a dense residential pocket unserved?
Is the pilot marketing geo fence actually covering the campus we care about?

Examples where the answer is often no:

We want the dashboard to look modern for a board offsite.
Leadership likes maps more than tables (taste is not a spatial join).
Region is already a clean categorical field and the decision is budget by region name.
You only have country-level data but someone asked for neighborhood heat.

Rule of thumb: If the insight survives when you shuffle points randomly inside the same city, you did not need geometry. You needed a group-by.

Good fit versus weak fit

Use this side-by-side as a gut check when a stakeholder says “can we map it?”

When geo helps: good fit for catchment, delivery radius, and store coverage versus weak fit for tiny n by hex, privac…

Good fit: catchment

Catchment analysis asks who or what falls inside a reachable area around a site: drive-time polygon, bike radius, or sales territory. Retail, clinics, field service, and schools use catchments constantly. The spatial question is real because distance and access change demand and cost.

Good fit: delivery radius

Delivery and service SLAs are spatial contracts. “We deliver within 5 miles” is not the same as “within 20 minutes at 5 p.m.” Distance in miles can be a start. Time-based isochrones are often closer to customer experience. Either way, location is not optional.

Good fit: store or asset coverage

Coverage asks whether assets sit where demand is. That includes stores, lockers, cell sites, EV chargers, and warehouses. Overlap and gaps are geometric facts. A ranked list of cities will not show a hole between two stores on the same highway corridor the way a map will.

Weak fit: tiny n by hex

Hex bins and grid cells are popular and often good. They become theater when each cell has two events and the color scale screams “hotspot.” Spatial aggregation does not create sample size. If counts are tiny, widen the bin, lengthen the time window, or switch to a non-map chart with confidence language.

Weak fit: privacy risk

Precise home addresses, patient locations, or employee residences can re-identify people even after you “remove names.” Aggregating to larger regions, suppressing small cells, and minimizing who sees point maps are part of the analysis design, not a polish step. If you cannot meet a privacy bar, geo may be the wrong presentation even when space matters operationally behind the scenes.

Weak fit: just pretty maps

Basemap chrome, animated flights of dots, and 3D extrusions can hide a missing question. If the only action is “wow,” you built marketing collateral. That can be intentional. Do not file it under decision analytics.

Beginner concepts that prevent rework

Unit of analysis

Are you studying stores, deliveries, customers, census tracts, or hex cells? Mixing units is how you double-count. A customer can place many orders; an order has one ship-to point; a store has one location and many customers. Pick the grain the way you would in any warehouse model. The metrics series habit of naming grain applies here with coordinates attached.

Join keys

Spatial analysis still needs keys. Sometimes the key is a region id (ZIP, FIPS, H3 index). Sometimes it is a point-in-polygon join from lat/long to a boundary. Sometimes it is a nearest-neighbor join to the closest store. Write the join type in the project card. “We mapped it” is not a join type.

Coordinate sanity

Latitude and longitude swapped, missing signs for the western hemisphere, geocodes landing in the ocean, and default zeros at (0,0) in the Gulf of Guinea are classic. Always plot a quick scatter or map sample before you trust aggregates. Null island is funny once.

Projection (light version)

The earth is not flat. For city-scale work, many tools handle distance well enough if you use their geography types correctly. For country-scale area comparisons, bad projections distort size. Beginners can go far by using library defaults designed for geodesic distance and by not computing Euclidean degrees as if they were meters. When area rankings matter a lot, partner with someone who knows CRS codes rather than inventing a custom formula at 1 a.m.

The geo project card

Before tools, fill a card. Part 2 will care about colors; Part 1 cares about whether you should start.

Geo project card with unit example store, join key lat/long or region id, and privacy set to aggregate only

Expand that card with three more lines in your wiki:

Field	Prompt	Example
Decision	What choice will this change?	Where to place a locker
Unit	What is one row in the fact?	Store or order ship-to
Join key	How does place attach?	lat/long to H3 or ZIP
Privacy	Point, aggregate, or suppressed?	Aggregate only
Success	How will we know the map helped?	Gap list with demand score
Non-goal	What are we not optimizing?	Pretty basemap branding

Worked example: store coverage sketch

Fictional city coffee chain with five stores. Leadership asks if the north side is “covered.” You refuse a vibes map and define coverage as: share of last-90-day orders whose ship-to (or customer home proxy) falls within a 1.5 km radius of at least one store. Privacy rule: no public point map of homes; use counts by grid cell of 1 km, suppress cells under 5 orders.

Toy store list:

Store	Lat	Lon
S1	40.74	-73.99
S2	40.73	-74.00
S3	40.76	-73.98
S4	40.71	-74.01
S5	40.75	-73.97

Pseudo-logic for “is order covered” (not production geospatial SQL; spirit only):

-- Conceptual: flag orders within 1.5 km of any store
SELECT
  o.order_id,
  o.grid_cell_id,
  MIN(distance_km(o.lat, o.lon, s.lat, s.lon)) AS km_to_nearest_store,
  MIN(distance_km(o.lat, o.lon, s.lat, s.lon)) <= 1.5 AS is_covered
FROM orders o
CROSS JOIN stores s
GROUP BY o.order_id, o.grid_cell_id;

Then aggregate:

SELECT
  grid_cell_id,
  COUNT(*) AS orders,
  AVG(CASE WHEN is_covered THEN 1.0 ELSE 0.0 END) AS coverage_rate
FROM order_coverage
GROUP BY grid_cell_id
HAVING COUNT(*) >= 5;

Output for leadership is not a constellation of home dots. It is a table of under-covered cells with order volume, plus an internal map of cells (not people). Decision language becomes: “Cells A12 and B7 have high demand and coverage under 40%; walk those blocks before approving store six.” That is geo helping.

Data you typically need

Points: stores, lockers, towers, delivery dropoffs
Addresses or coordinates: geocoded with a quality flag
Boundaries: ZIP, city, district, custom territories
Optional network context: drive-time when road distance matters
Attribute facts: revenue, orders, incidents, population proxies

Geocoding quality deserves a column: match score, partial match, rooftop versus centroid. Centroid of a huge ZIP is not a home. If your join key is weak, your map will be confidently wrong. Treat that as a data quality issue with the same seriousness you would bring to the data quality series.

Common mistakes

Starting in the map UI before writing the decision.
Publishing point maps of sensitive people data.
Choroplething raw counts without population or opportunity denominators (Part 2 deep dive).
Using country-level data to answer street-level questions.
Ignoring geocode failures that silently drop rural or apartment addresses.
Treating region names as geometry when spellings differ across systems.
Overfitting a hotspot story on a week of data with tiny n.

How to practice

Pick one real decision at work that mentions place. Write the decision test answer in two sentences.
Fill a geo project card (unit, join key, privacy, success, non-goal).
Plot 50 sample points from your data (or open sample city data) and fix any coordinate insanity before aggregates.
Compute a simple coverage or distance metric in a table first; only then draw a map.
List three stakeholder asks that should be rejected as pretty-only. Practice the polite no.

Next in this series: maps that inform without misleading, including choropleth rates, binning, and missing regions. For broader analytics learning paths, use the Learn hub. Stewardship and access control for location data sit next to general privacy habits in the data stewardship series.

Quick recap

Geo helps when location changes the decision, not when maps merely impress.
Good fits include catchment, delivery radius, and coverage problems.
Weak fits include tiny-n heat, privacy-unsafe points, and decoration.
Name unit, join key, and privacy before you pick tools.
Tables and project cards beat basemap tourism.
Coordinate and geocode quality are data quality problems with lon/lat costumes.

Sources

PostGIS. Documentation on geography types and spatial joins (foundational open-source spatial SQL concepts). https://postgis.net/documentation/
GeoPandas. User guide (Python vector geospatial workflows for analysts). https://geopandas.org/en/stable/docs.html
Uber Engineering. H3 docs (hexagonal hierarchical spatial index used widely for binning). https://h3geo.org/docs/
US Census Bureau. Geography program and TIGER/Line resources (public boundaries many US analyses join to). https://www.census.gov/programs-surveys/geography.html
OpenStreetMap. About and data use notes (common basemap and geodata ecosystem; respect licenses). https://www.openstreetmap.org/about