Open barbeau opened 8 years ago
Proposal to clarify GTFS-rt spec was accepted and merged - https://github.com/google/transit/pull/16.
From recent discussions it sounds like this is an issue in the Puget Sound area with real-time info seen by OneBusAway users.
In the "Stop Time Updates" section, the GTFS-realtime spec (https://developers.google.com/transit/gtfs-realtime/trip-updates#stop-time-updates) says:
My interpretation of the highlighted portion is that when multiple StopTimeUpdates exist in a trip (i.e., per-stop predictions), individual StopTimeUpdates shouldn't be dropped from the GTFS-rt feed if the vehicle is running ahead of schedule until after the scheduled arrival time for that stop (from GTFS stop_times.txt).
For example, if the following data appears in the GTFS-rt feed:
...the prediction for Stop 4 cannot be dropped from the feed until 10:21am, even if the bus actually passes the stop at 10:18am. If the StopTimeUpdates for Stop 4 was dropped from the feed at 10:18am or 10:19am, and the scheduled arrival time is 10:20am, then the consumer should assume that no real-time information exists for Stop 4 at that time.
A vendor is arguing that this text applies only to the TripUpdate, not to the StopTimeUpdates, and they are allowed to drop updates for vehicles running early as soon as the vehicle passes the stop (no matter what the scheduled arrival time is). If the vendor's interpretation is correct, it results in a very poor end user experience for consumers - for example, if a vehicle was running 5 minutes early, and the user checks their app 4 minutes before the scheduled arrival time, the app would only show scheduled information, and would show that the vehicle was expected to arrive in 4 minutes (even though at a system level we know that the vehicle already passed the stop).
Also, in OneBusAway, riders like to see negative ETAs that indicate that a bus just left, so they know if they just missed a bus (vs. facing the unknown and wondering if they actually just missed the bus, or if the system doesn't have information about that bus). However, we can't show these negative arrivals (early, on time, or late) if the producer drops the update as soon as the vehicle passes, as we would only show scheduled negative arrival times. Technically dropping on time or late arrivals after the vehicle passes the stop is allowed by the GTFS-rt spec, but in terms of best practices I would recommend that they remain in the feed for at least another few minutes and/or stops.
Related proposal to clarify the GTFS-rt spec here - https://github.com/google/transit/pull/16.
The problems this created in OneBusAway are outlined here - https://github.com/OneBusAway/onebusaway-application-modules/issues/162.
Discussion on the GTFS-realtime group - https://groups.google.com/forum/#!topic/gtfs-realtime/3rAf6UIhAsQ.
So, new rule that's required behavior:
StopTimeUpdate
if it refers to a stop with a scheduled arrival time in the future for the given trip (i.e. the vehicle has passed the stop ahead of schedule)New rule that's optional behavior (best practice):