DS-01 · Predicting when the bus is actually coming

GRTC publishes a schedule and a real-time feed. How far apart are they, and can you predict the gap for a given route, stop, and time of day better than assuming the bus is on time?

GRTC static GTFS (via Transitland mirror of the agency zip) (https://www.transit.land/feeds/f-grtc~va). Supplement with NOAA hourly weather for the Richmond area (https://www.ncei.noaa.gov/products/land-based-station/global-historical-climatology-network-daily). A public GTFS-Realtime developer endpoint is not currently published — treat real-time capture as a design problem (documented bus-tracker sampling, or schedule-only with an honest baseline). Whatever you collect, start early: eight weeks of capture beats four days of padding.

Realtime feeds drop out for hours and the gaps look like on-time performance. Trip IDs change between schedule versions and silently break joins. Rush-hour and midday behave like different problems. Predicting delay in minutes looks easy because most buses are near-zero — the model learns to say "on time" and scores well.

A model that predicts arrival delay at a named stop, evaluated against the "assume the schedule" baseline, with error broken out by time of day and route — plus an honest statement of how many hours of feed were actually captured.

CT: choosing an error metric that punishes the costly direction (early buses strand riders; late buses annoy them). CR: designing the collection pipeline before there is data to analyze. CO: comparing capture logs with a peer to find dropouts. CM: a rider- facing explanation of what "3 minutes late, usually" means. CZ: who is harmed by an unreliable bus, and does the error concentrate on particular routes.

A transit planner, data engineer, or logistics analyst reviews the collection design at Checkpoint 1 and the error analysis at Checkpoint 2. School- supervised, both times.

R1: the question is narrowed to specific routes and hours, with a stated reason. R2: collection gaps are logged and reported, not hidden. R3: beats the schedule baseline, and the student can say which conditions drive the gain. R4: error split by hour and route, with the early/late asymmetry addressed. R5: a rider could read it. R6: names which riders bear the worst predictions.

(a) The student starts collecting in week six, has four days of data, and pads with schedule-only rows — the model learns the schedule and reports excellent accuracy. (b) The student reports mean absolute error of 2 minutes and calls it a success, without noticing every large error is on one late-night route.