Data methodology

Departures and predictions

Scheduled departures come from the currently imported GTFS service calendar. A realtime departure is shown only when an OC Transpo trip update can be matched to the scheduled trip and stop.

Cancellation and skipped-stop relationships are displayed explicitly. Failed, malformed, unexpectedly empty, stale, or partially failed feeds are not called healthy. When live data is missing, the schedule remains labelled scheduled.

Trip planning and accessibility

Trip plans come from the configured OpenTripPlanner graph built from the imported transit feed and routing data. Otranspo does not invent a fallback itinerary.

Wheelchair and step-free preferences are sent to the routing engine. Each returned leg retains the source accessibility state; missing states remain unknown.

Public report patterns

Individual reports are private. Public patterns include only moderator-confirmed non-safety and non-operator reports grouped by category and route, with at least five reports in each cohort.

A public count is community-submitted evidence, not an operator-confirmed incident count.

Operational status

Status is computed from direct probes of the database, current migrations, imported schedule, routing engine, independent realtime feeds, durable worker, email, storage, geocoder, and required configuration. Optional components degrade independently.