# Building a Municipal Transit Planner That Survives Real Streets

A municipal transit planner is not just a shortest-path problem with buses attached. Riders care about wait time, transfer confidence, walking safety, accessibility, service reliability, and whether the trip still works when a snow route or construction detour appears at 7:15 a.m. The system has to combine scheduled service, real-time vehicle positions, pedestrian networks, stop metadata, fares, and operational alerts into one answer that is both fast and explainable.

## Data Inputs

The baseline usually starts with GTFS for scheduled service and a city-maintained GIS layer for streets, sidewalks, crossings, bike lanes, elevators, and station entrances. In practice, data quality work takes as much time as routing logic: stop IDs drift across vendors, curb ramps are missing, temporary stops are posted as PDFs, and walking paths that look valid on a map may cross private property or unsafe intersections.

```yaml
routing:
  max_walk_minutes: 18
  transfer_penalty_minutes: 6
  realtime_staleness_seconds: 90
  accessibility_required: false
```

## Routing Engine

The planner should use a time-dependent graph rather than a static network, because a route that is optimal at 8:02 may be poor at 8:07 after a missed headway. A practical implementation precomputes schedule-based transfer patterns, then adjusts edge costs at query time using vehicle predictions, cancelled trips, elevator outages, and local policy rules such as avoiding unlit pedestrian paths after dark.

## Operations Integration

The hardest feature is often detour handling. Dispatchers need a workflow that can publish a temporary stop closure or reroute once and have it affect trip planning, passenger alerts, onboard announcements, and open data feeds. That means the planner should consume operational events as structured records, not free-text messages that riders and software interpret differently.

## Lessons Learned

A good municipal transit planner must be observable and auditable. When a rider asks why the app suggested a 12-minute walk instead of a nearby transfer, staff should be able to inspect the decision: stale real-time data, transfer risk, accessibility filters, missing stop amenities, or a blocked sidewalk segment. The planner is successful when it makes the city’s transportation network legible without hiding the messy operational reality behind it.