# Building a Municipal Transit Planner That Survives Real Streets

A municipal transit planner looks simple from the outside: enter an origin, choose a destination, and receive an itinerary. In production, it must reconcile scheduled service, street geometry, accessibility constraints, transfer rules, and live disruptions. Our planner combines General Transit Feed Specification (GTFS) data with a pedestrian routing graph, then evaluates candidate journeys using arrival time, walking distance, transfer count, and service reliability.

## Data Ingestion and Validation

Each nightly import loads stops, routes, trips, stop times, calendars, and exceptions into versioned tables. Validation runs before publication because small feed errors can produce convincing but unusable results. The pipeline rejects trips with non-monotonic stop times, flags stops located far from their route geometry, and verifies that every referenced service calendar exists. New datasets are activated atomically, allowing in-flight requests to finish against the previous version.

## Journey Search

Routing uses a round-based public transit algorithm similar to RAPTOR. The first round finds trips reachable without transfers; subsequent rounds expand journeys through transfer points. Walking edges connect nearby stops, but their cost depends on slope, crossing type, construction closures, and wheelchair accessibility. To keep response times predictable, the API limits transfer rounds and prunes candidates that are already dominated by faster, simpler journeys.

```yaml
routing:
  max_transfers: 3
  max_walk_meters: 1200
  transfer_buffer_seconds: 90
  wheelchair_accessible_only: false
```

## Real-Time Service Updates

Vehicle positions and trip updates arrive every 15 to 30 seconds from the operations system. Rather than rebuilding the routing graph, the planner overlays delays, cancellations, and stop closures onto the static schedule. Updates carry expiration times so stale operational data cannot suppress service indefinitely. When real-time information is unavailable, the response explicitly falls back to scheduled times and exposes that status to client applications.

## Operating the Planner

We monitor routing latency, feed age, failed itinerary searches, and the percentage of journeys altered by live updates. Synthetic requests cover common commuter trips, late-night service, accessible routes, and transfers near municipal boundaries. The most useful operational metric is not raw uptime but successful journey quality: whether the planner returns an itinerary that a rider can realistically complete under current street and service conditions.