Purpose: replace as-the-crow-flies guesswork with network-true travel costs, at the right scale and with honest assumptions about speeds and modes. First decision on every task: Euclidean distance is only acceptable as a declared approximation — flag it whenever you see it standing in for access.
Tool selection by scale
| Scale | Tool |
|---|---|
| Neighborhood-city, research flexibility | OSMnx + NetworkX |
| City-region, many-to-many OD (>10⁴×10⁴) | r5py (multimodal + transit w/ GTFS) or pandana (contraction-hierarchy speed) |
| Production routing service | Valhalla / OSRM / OpenRouteService API |
| Proprietary stacks | ArcGIS Network Analyst (script it headlessly) |
NetworkX chokes on metro-scale many-to-many — don't loop shortest_path
over thousands of origins; switch tools instead.
Graph construction (OSMnx)
import osmnx as ox
G = ox.graph_from_place("City, Country", network_type="drive") # walk/bike/all
G = ox.add_edge_speeds(G) # imputes from highway tags where maxspeed missing
G = ox.add_edge_travel_times(G) # edge attr: travel_time (s)
G = ox.project_graph(G) # metric CRS before any distance work
- network_type matters: pedestrian analysis on a
drivegraph misses paths, stairs, plazas; driving onalluses footpaths. Match mode. - Imputed speeds are averages by road class — a systematic bias, not noise. State it; calibrate against known trips when stakes are high.
- Keep the strongly connected component for routing
(
ox.truncate.largest_component(G, strongly=True)); orphan islands cause spurious infinities. - Snapping: origins/destinations map to nearest nodes/edges
(
ox.distance.nearest_nodes). Report the snap-distance distribution; a facility snapped 2 km away (riverside, gated area) silently corrupts results.
Core products
- Isochrones / service areas: ego-graph by travel_time cutoff → alpha shape or buffered edge union around reached edges. Node-based convex hulls overstate coverage across rivers/highways — prefer edge-based polygons. Always label the assumptions: mode, speed model, cutoff.
- OD matrix: many-to-many travel costs; the substrate for accessibility and location-allocation. For big matrices use pandana/r5py; store as Parquet with origin/destination IDs.
- Closest facility: k-nearest by network cost (not Euclidean); report both the assigned facility and the cost.
- Centrality: betweenness on travel_time (sampled
kfor big graphs — exact is O(nm)); edge betweenness ≈ through-traffic potential. Interpret as network structure, not observed traffic.
Accessibility metrics — pick deliberately
| Metric | Question it answers | Weakness |
|---|---|---|
| Cumulative opportunities (# jobs/POIs within T min) | Simple, communicable | Cliff at T; all-or-nothing |
| Gravity-based (distance-decayed sum) | Smooth access | Decay parameter must be justified |
| 2SFCA / E2SFCA | Supply-demand ratio access (health care standard) | Catchment size choice drives results |
| Closest-facility time | Worst-case need | Ignores capacity/congestion |
For equity analyses, join metrics to population/demographic polygons
(area-weighted or dasymetric — see geo-data-engineering) and report
distributions per group, not just city means. Route statistical testing of
disparities to spatial-statistics.
Location-allocation
Optimal siting (p-median, max-coverage) on the OD matrix: formulate with
PuLP/OR-Tools; inputs are the OD matrix + demand weights + candidate
sites. State the objective explicitly — minimize mean travel time
(p-median) vs maximize covered demand within T (max-coverage) give
different answers, and stakeholders rarely know which they asked for.
Feed results back to mcda-suitability-analysis when siting mixes network
access with other criteria.
Transit (GTFS)
Use r5py with OSM + GTFS feeds; results are departure-time sensitive — compute over a time window (e.g., 07:00-09:00 percentiles), never a single departure. Validate the feed (calendar coverage on your analysis date!) — an expired GTFS calendar yields walking-only times that look plausible.
Verification protocol
- Spot-check 3 routes against an external router (Google/OSRM) — within ~20% or explain why.
- Map unreachable/infinite-cost pairs — usually snapping or connectivity artifacts, not real inaccessibility.
- Isochrone eyeball: does it respect rivers, highways, one-ways?
Pitfalls checklist
- Euclidean buffers presented as "service areas".
- Wrong network_type for the mode.
- Convex-hull isochrones bridging barriers.
- Snap distances unchecked.
- One departure time for transit accessibility.
- Betweenness sold as traffic volume.
- OD matrix in degrees-CRS travel "distances".
Execution contract
- Workflow: define mode, time, impedance, origins, destinations, and equity question; build and validate the network; snap inputs; compute routes or matrices; summarize access; verify.
- Decision rules: use network costs for constrained travel, movement analytics for observed tracks, and MCDA only when accessibility becomes one criterion in a broader preference model.
- Verification protocol: audit connectivity and snapping, spot-check routes, map unreachable pairs, test departure-time or impedance sensitivity, and reconcile OD dimensions and units.
- Failure modes: withhold access claims for disconnected graphs, wrong mode or turn rules, expired GTFS service, excessive snapping, Euclidean substitution, or unstable departure-time results.
- Deliverables: network provenance, assumptions and cost function, routes or OD matrix, isochrones or access metrics, unreachable-case report, validation evidence, and equity caveats.
- Source freshness: consult the authoritative source registry before using network, GTFS, or routing APIs and archive source dates.