# Building a Municipal Transit Planner That Handles Real Streets

Municipal transit planning looks simple on a map: connect neighborhoods to schools, hospitals, commercial districts, and regional rail. In practice, every proposed route must balance competing constraints such as operating cost, driver availability, accessibility, traffic conditions, and political commitments. Our planning system combines scheduled service data with street geometry, population estimates, and anonymized boarding counts so planners can compare alternatives before committing vehicles or changing timetables.

## Modeling the Network

We represent the transit network as a time-dependent graph. Stops are vertices, while walking links and scheduled vehicle trips form edges whose costs vary by departure time. General Transit Feed Specification (GTFS) files provide the baseline schedule, but they are not sufficient on their own: construction detours, school-day calendars, transfer penalties, and wheelchair-accessible paths must be incorporated during import. Each dataset is versioned so a scenario can be reproduced months after a public consultation.

A typical scenario configuration stays deliberately small and reviewable:

```yaml
service_date: 2026-09-15
max_walk_minutes: 12
transfer_penalty_minutes: 6
require_accessible_paths: true
```

## Evaluating Service Changes

When a planner moves a stop or changes a route frequency, the system recalculates travel times for a representative sample of origin-destination pairs. We report median travel time, missed-transfer risk, vehicle-hours, and the percentage of residents who can reach key destinations within 30 or 45 minutes. Results are also segmented by neighborhood and mobility needs; an apparently efficient redesign can otherwise conceal a severe loss of access for a small population.

## Keeping Recommendations Operational

The routing engine does not decide what the city should build. Instead, it exposes tradeoffs and flags proposals that violate operational rules, such as insufficient recovery time at a terminal or a turn that standard buses cannot safely make. Planners can override warnings, but every override requires a note and remains attached to the scenario, creating an audit trail for engineering review and council reports.

## Lessons from Deployment

The hardest problems have been data quality and institutional workflow, not pathfinding performance. Stop coordinates drift, passenger counters fail, and temporary detours become semi-permanent without reaching the source feed. A useful municipal transit planner therefore needs visible provenance, conservative defaults, and straightforward exports as much as it needs a fast routing algorithm. Trust grows when staff can trace every metric back to a schedule version, a dataset, and an explicit assumption.