search

MobilityData / gtfs-realtime-validator

Java-based tool that validates General Transit Feed Specification (GTFS)-realtime feeds
Other
41 stars 10 forks source link

Per stop predictions - providers shouldn't drop arrivals until after the bus passes the stop #11

Closed barbeau closed 2 years ago

barbeau commented 2 years ago

Issue by barbeau Tuesday Jan 12, 2016 at 21:45 GMT Originally opened as https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/16

In the "Stop Time Updates" section, the GTFS-realtime spec (https://developers.google.com/transit/gtfs-realtime/trip-updates#stop-time-updates) says:

A trip update consists of one or more updates to vehicle stop times, which are referred to as StopTimeUpdates. These can be supplied for past and future stop times. You are allowed, but not required, to drop past stop times. When doing this, be aware that you shouldn't drop a past update if it refers to a trip that isn't yet scheduled to have finished (i.e. it finished ahead of schedule) as otherwise it will be concluded that there is no update on this trip.

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:

Stop 4 –Predicted at 10:18am (scheduled at 10:20am – 2 min early)
Stop 5 –Predicted at 10:30am (scheduled at 10:30am – on time)

...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:

New rule that's optional behavior (best practice):

barbeau commented 2 years ago

Comment by barbeau Friday Jul 07, 2017 at 15:55 GMT

Proposal to clarify GTFS-rt spec was accepted and merged - https://github.com/google/transit/pull/16.

barbeau commented 2 years ago

Comment by barbeau Thursday Jan 25, 2018 at 17:20 GMT

From recent discussions it sounds like this is an issue in the Puget Sound area with real-time info seen by OneBusAway users.