# Building a Municipal Transit Planner That Survives the Real World

Municipal transit planning looks like a shortest-path problem until real operational data enters the system. A useful planner must combine scheduled service, live vehicle positions, street geometry, accessibility constraints, and local policies such as minimum transfer times. We modeled the network from GTFS feeds, representing stops as nodes and scheduled trips as time-dependent edges, then added walking links generated from the city’s pedestrian network.

## Routing Beyond the Fastest Trip

Our routing engine uses a multi-criteria variant of Dijkstra’s algorithm. Instead of optimizing only arrival time, it retains candidate journeys based on transfers, walking distance, fare, and accessibility. This matters because a trip arriving two minutes earlier may require an unreliable connection or a long walk between platforms. Configurable penalties let planners tune results without rebuilding the graph.

```yaml
routing:
  transfer_penalty: 6m
  max_walking_distance: 900m
  wheelchair_accessible: true
```

## Handling Live Service Conditions

Real-time updates arrive through GTFS-Realtime feeds for delays, cancellations, and vehicle positions. Rather than reconstructing the entire graph whenever a bus falls behind schedule, the service applies temporary edge-weight overrides with expiration timestamps. If live data becomes stale, the planner falls back to the published timetable and clearly labels the result as scheduled rather than predicted.

## Designing for Municipal Data

Public-sector datasets are rarely uniform. Stop identifiers change between annual schedule releases, road closures may arrive as spreadsheets, and neighboring agencies often publish overlapping stops with different coordinates. An ingestion pipeline validates referential integrity, flags suspicious coordinate changes, and preserves source versions so staff can reproduce the journey options shown on a particular date.

## Operations and Accountability

The production service exposes routing latency, feed freshness, failed imports, and prediction accuracy as operational metrics. It also records which data versions and routing parameters produced each itinerary, without storing unnecessary rider information. That audit trail has proven as important as routing speed: when residents or council staff question a recommendation, planners can explain exactly how the system reached it.