# Building a Municipal Transit Planner That Reflects Real Streets

Municipal transit planning looks simple on a map: connect neighborhoods to schools, hospitals, commercial districts, and regional rail. In production, however, every route is constrained by road geometry, vehicle capacity, labor rules, accessibility requirements, and inconsistent source data. Our planner combines scheduled service, street-network data, and anonymized ridership counts to evaluate proposed bus routes before planners commit to a costly field trial.

## Modeling the Network

The system represents stops and intersections as nodes in a directed graph, with edges weighted by expected travel time rather than distance. Each weight includes historical congestion, dwell time, turn penalties, and restrictions such as low-clearance bridges. Because traffic conditions vary throughout the day, the planner stores separate weights for weekday peaks, midday service, evenings, and weekends.

```yaml
routing:
  transfer_penalty_seconds: 420
  minimum_layover_seconds: 300
  wheelchair_boarding_seconds: 45
```

## Evaluating Service Changes

For each proposal, the planner runs thousands of origin-destination journeys and compares travel time, transfer count, walking distance, and missed-connection risk against the existing network. Results are grouped by census block rather than reported only as citywide averages; otherwise, a route that improves downtown service can conceal significantly worse access in an outer neighborhood. Planners can also lock essential stops so optimization never removes service from hospitals, shelters, or mobility hubs.

## Working With Imperfect Data

Automatic passenger counters occasionally fail, GPS observations arrive late, and temporary detours can distort historical travel times. The ingestion pipeline assigns confidence scores to each observation and rejects impossible movements, such as a bus traveling several kilometers between consecutive five-second samples. When recent data is sparse, the model falls back to seasonal medians and clearly marks the resulting estimates as lower confidence.

## From Simulation to Deployment

A technically optimal route is not automatically operationally feasible, so shortlisted plans are reviewed for driver relief points, safe turning movements, charging windows, and schedule recovery time. Approved changes are first published to a staging General Transit Feed Specification feed, validated against the production timetable, and tested with dispatch staff. After launch, the same metrics used during simulation are monitored for several service periods, allowing the city to distinguish normal adjustment noise from changes that require a timetable or routing correction.