Transit Method

Thunder Bay Transit publishes GTFS schedule and realtime feeds — the same standard behind Google Maps and NextLift. Those apps show where buses are now and discard the data. We store every position, delay, and cancellation as a raw event.

A background job periodically rolls the raw events into the aggregates shown on the Metrics tab. All metrics are measured at timepoint stops (the ones marked timepoint=true in the GTFS feed).

“Without an explicit SLO, users often develop their own beliefs about desired performance, which may be unrelated to the beliefs held by the people designing and operating the service.”

Google authored the GTFS transit standard and publishes the SRE Handbook openly. The handbook’s framing of indicators and objectives shapes how this site reasons about transit service quality.

The handbook calls its metrics service level indicators (SLIs) — the same idea as a Key Performance Indicator (KPI), but focused on what the user experiences rather than what the operator reports. An indicator becomes a service level objective (SLO) when stakeholders commit to a target: not just “we track on-time performance” but “we agree 75% is the floor.”

These metrics can’t tell you whether every rider got where they needed to be. What they can do is show whether the system is trending in the right direction over time.

Each service day is sliced into three six-hour windows. Every metric is computed per window, per route. Chunks store raw counts and sums — not percentages. A weekly or system-wide number sums the counts across chunks and divides once at the end, so a busy route with 200 trips outweighs a quiet one with 10 instead of both counting the same.

Once a window closes the chunk is sealed and never changes. Midnight to 6 AM has no chunk — a handful of late-night trips run in that window, but not enough to produce meaningful metrics, so we leave them out.

A trip is "on time" if it arrives within 1 minute early to 5 minutes late of schedule. This window is the standard definition used by most North American agencies.

Early departures are penalized because if a bus leaves a stop before the scheduled time, you miss it — that's worse than a bus running late.

CV is the coefficient of variation of headways — the standard deviation of gaps between buses, divided by the average gap. If buses arrive at perfectly even intervals, CV is zero — regardless of whether those intervals match the published schedule. In practice, buses bunch up or leave big gaps — the higher the number, the more unpredictable your wait becomes.

Think of it like darts. The bullseye is the average gap between buses. Each actual arrival is a throw. Low CV means the darts cluster around the bullseye — gaps between buses stay consistent. High CV means darts scattered across the board — gaps are all over the place.

CV only judges regularity, not whether the bus is on time. A route that runs every 20 minutes when the schedule says every 10 still has CV = 0 if those gaps are perfectly even. To see whether the service matches the schedule, look at EWT below.

Excess Wait Time, as defined by Transport for London, is the operational metric we lean on most. The published schedule sets an expected average wait. EWT measures how many extra minutes you actually wait beyond that, because buses aren’t arriving at regular intervals — the gap between the schedule and what actually happens.

If a route runs every 15 minutes, you'd expect to wait 7.5 minutes on average. But if two buses arrive together and then nothing comes for 30 minutes, the average headway is still 15 minutes — yet the experience is far worse. EWT captures exactly this gap.

Why does EWT matter more than average delay? Because it counts riders, not just buses. A long gap doesn’t just mean one late bus — it means every rider who arrived during that gap is waiting at the stop. The longer the gap, the more riders accumulate, and the longer each waits. EWT weights gaps by the number of riders they affect, so it measures rider wait time rather than vehicle timing.

The two timelines below have the same average headway (15 min), but the rider experience is very different:

Bigger gaps affect more riders, because more riders arrive during them. EWT captures that — it weights each gap by how many riders it affects, then subtracts the wait you’d expect if buses ran on schedule.

The route finder uses RAPTOR (Round-bAsed Public Transit Optimized Router), an algorithm developed at Microsoft Research for computing optimal multi-leg transit journeys. RAPTOR works directly on the timetable — scanning routes round by round, where each round adds one more vehicle. Round 1 finds all destinations reachable by a single bus, round 2 finds journeys with one transfer, and so on. Because of this, RAPTOR is more efficient compared to graph-based approaches like Dijkstra or A* for transit routing.

Thunder Bay Transit publishes three GTFS Realtime feeds — vehicle positions, trip updates, and service alerts. We poll each on a fixed interval and store every response as a raw event. The official feed URLs are listed on the City of Thunder Bay Transit Open Data page.

The feeds are encoded as Protocol Buffers (protobuf) — a compact binary serialization format.