Fix: impossibly fast travel between distant stops
Published: . Last reviewed: .
Code: fast_travel_between_far_stops (MobilityData validator)
What this means
Between two stops that are far apart, the scheduled times imply a speed no bus reaches. The usual causes: an arrival or departure time typed a minute or an hour off, a stop placed at the wrong coordinates so the distance is inflated, or a missing stop between the two that would have broken the leg up.
Why it matters
A rider planning around these times gets an itinerary that cannot happen; a realtime system comparing predictions to this schedule reports phantom delays. Either way, the feed promises something the street cannot deliver, and the rider pays for the gap.
How to fix it
- Check the times first. Open the flagged trip and look at the two stop times; a transposed digit or wrong hour is the most common cause.
- Then check the stop locations. If a stop sits miles from where the bus actually stops, correcting its coordinates fixes the implied speed and every other check that uses that stop.
- Then check for a missing stop. If the vehicle really serves a stop between the two, adding it back splits the leg into plausible pieces.
How long it usually takes
Minutes per flagged trip once you open it: these are almost always a typo, a misplaced pin, or a dropped stop, each visible at a glance.
Authoritative rule
fast_travel_between_far_stops is a canonical MobilityData GTFS Validator notice used in validator reports across the GTFS ecosystem. Read the authoritative rule for fast_travel_between_far_stops in the GTFS Validator rules. (opens on an external site)
After you republish
Once the changed feed is live at your published URL, the next scorecard run checks it again. When the same complete producer contract no longer reports this finding, it can be recorded as a dated finding clearance. That confirms the later feed state, not who changed the feed or why.