gtfs-realtime-validator
gtfs-realtime-validator copied to clipboard
Should early arrivals/departures be propagated across timepoints?
Summary:
Doesn't affect our GTFS-rt validator tool, but I wanted to capture this here so I can revisit with GTFS-rt community.
IMHO, early arrivals/departures should not be propagated past stops labeled as timepoints, as the vehicle would be expected to wait at the timepoint until it catches up with the schedule.
I previously posted about this to the GTFS-rt list, but only one operator responded (he did agree with me): https://groups.google.com/forum/#!searchin/gtfs-realtime/timepoint|sort:relevance/gtfs-realtime/IjLaWmLnvbk/F65uYPzjCwAJ
In GTFS, we now have a timepoint field in stop_times.txt, which has the definition:
The timepoint field can be used to indicate if the specified arrival and departure times for a stop are strictly adhered to by the transit vehicle or if they are instead approximate and/or interpolated times.
If an agency specifies "timepoint=1" for a stop in stop_times.txt, should a GTFS-rt consumer propagate negative delays (i.e., buses running ahead of schedule) downstream through these timepoints*?
In theory, if the bus operator is adhering to the timepoint, they should hold the bus until they are back on schedule (i.e., a 0 delay). In this situation, it would make sense to change to a 0 delay value at the timepoint stop, and propagate this 0 delay down the line from the timepoint on. It's likely that this would be a more reasonable estimate of when the bus would arrive for stops downstream of the timepoint, rather than a negative delay propagated from further upstream down through the timepoint.
I'm also interested to hear from any GTFS producers providing timepoint values if their vehicles do indeed follow this behavior for stops marked with "timepoint=1".
- Assuming that a delay or time value is provided by the GTFS-rt producer for a stop upstream of the timepoint, but not at the timepoint or downstream of the timepoint.