# Building a Municipal Transit Planner That Survives Real-World Operations

A municipal transit planner looks simple from the passenger’s perspective: enter an origin and destination, then receive a route. Behind that interaction is a constantly changing network of stops, walking paths, schedules, service calendars, accessibility constraints, and live vehicle data. Our planner combines static GTFS feeds with real-time updates, normalizes them into a versioned network graph, and publishes validated snapshots so routing requests never observe a partially imported timetable.

## Modeling Time-Dependent Routes

Unlike ordinary road navigation, transit edges are time-dependent. A bus connection is useful only if the rider can reach the stop before departure, while transfers must account for walking time, station layout, and minimum interchange rules. We use a modified RAPTOR search because it processes routes by transfer rounds and performs well across large timetable datasets without expanding every scheduled trip into a conventional graph edge.

```yaml
routing:
  max_transfers: 3
  minimum_transfer_seconds: 120
  wheelchair_accessible_only: false
  realtime_staleness_seconds: 90
```

## Integrating Real-Time Operations

Vehicle positions alone are not enough to adjust a journey. The planner consumes trip updates, cancellations, stop-level delays, and service alerts, then maps each event back to the correct scheduled trip. When real-time data becomes stale or inconsistent, the system falls back to the published schedule and marks the result accordingly rather than presenting an uncertain prediction as an exact arrival time.

## Designing for Municipal Constraints

Public-sector deployments introduce requirements that are easy to overlook in prototypes. The service must support bilingual stop names, accessible itineraries, low-bandwidth devices, audit logs, and predictable behavior during vendor outages. It must also preserve historical timetable versions so staff can reproduce a route recommendation after a complaint, policy review, or accessibility investigation.

## Measuring What Riders Experience

Infrastructure metrics such as CPU usage and request latency are necessary but incomplete. We also track impossible transfers, missed real-time matches, itinerary churn, excessive walking, and the percentage of searches that return no route. These measures are segmented by neighborhood, time of day, and accessibility preference because a planner can appear healthy overall while consistently underserving a specific district or group of riders.