All StopTimeUpdates within a TripUpdate contain predictions in the past

[isabelle-dr]

Issue by barbeau
Oct 24, 2019
Originally opened as CUTR-at-USF#357

---

Summary:

If a TripUpdate contains only stop_times_updates for arrival/departure times in the past, this is a warning.

I'd like for this to be an error, but currently the GTFS-rt spec (https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/trip-updates.md#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.

This can be interpreted as all stop_time_updates in a TripUpdates could be in the past. IMHO this means that some of the stop_time_updates in a TripUpdate can occur in the past, but there should be at least one stop_time_update with a future arrival or departure time for it to be a valid prediction. Otherwise consumers should consider the TripUpdate invalid and assume that no real-time information exists for the trip.

So, I'd like for the spec to be changed to say something like:

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, although each TripUpdate must contain at least one StopTimeUpdate with an arrival or departure time in the future. You are allowed, but not required, to drop past stop times.

Steps to reproduce:

Run the validator against a feed that contains a TripUpdate that only contains stop_time_updates with arrival and departure times in the past.

Expected behavior:

The validator should flag this as a warning.

Observed behavior:

No warnings are flagged.

[isabelle-dr]

Comment by barbeau
Oct 29, 2019

---

Note that we'd need to carve out an exception for this case (from https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/trip-updates.md):

Producers should not drop a past 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), as otherwise it will be concluded that there is no update for this stop.

[isabelle-dr]

Comment by barbeau
Oct 29, 2019

---

Producers may be publishing stale predictions in the case where the AVL system doesn't actually support predictions, just observed schedule deviation, which would be generated as the vehicle passes the stop. Therefore, it may be worthwhile to add observed schedule_deviation as an attribute of the vehicle and change TripUpdates to contain only predictions. It would give agencies a better place to publish this data and may avoid this type of issue.

[e-lo]

Added from #137

Need Consistency between Best Practices text and the existing warning: E041.

Relevant Best Practice text:

All TripUpdates should include at least one stop_time_update with a predicted arrival or departure time in the future. If all stop_time_updates for a trip reference past arrival and departure times, consumers should assume that no real-time data is available for the trip.

E041 Text

Unless a trip's schedule_relationship is CANCELED, a trip must have at least one stop_time_update