Realtime update of the progress of a vehicle along a trip.
Depending on the value of ScheduleRelationship, a TripUpdate can specify:
A trip that proceeds along the schedule.
A trip that proceeds along a route but has no fixed schedule.
A trip that have been added or removed with regard to schedule.
The updates can be for future, predicted arrival/departure events, or for
past events that already occurred.
Normally, updates should get more precise and more certain (see
uncertainty below) as the events gets closer to current time.
Even if that is not possible, the information for past events should be
precise and certain. In particular, if an update points to time in the past
but its update's uncertainty is not 0, the client should conclude that the
update is a (wrong) prediction and that the trip has not completed yet.
Note that the update can describe a trip that is already completed.
To this end, it is enough to provide an update for the last stop of the trip.
If the time of that is in the past, the client will conclude from that that
the whole trip is in the past (it is possible, although inconsequential, to
also provide updates for preceding stops).
This option is most relevant for a trip that has completed ahead of schedule,
but according to the schedule, the trip is still proceeding at the current
time. Removing the updates for this trip could make the client assume
that the trip is still proceeding.
Note that the feed provider is allowed, but not required, to purge past
updates - this is one case where this would be practically useful.
Realtime update of the progress of a vehicle along a trip. Depending on the value of ScheduleRelationship, a TripUpdate can specify:
The updates can be for future, predicted arrival/departure events, or for past events that already occurred. Normally, updates should get more precise and more certain (see uncertainty below) as the events gets closer to current time. Even if that is not possible, the information for past events should be precise and certain. In particular, if an update points to time in the past but its update's uncertainty is not 0, the client should conclude that the update is a (wrong) prediction and that the trip has not completed yet.
Note that the update can describe a trip that is already completed. To this end, it is enough to provide an update for the last stop of the trip. If the time of that is in the past, the client will conclude from that that the whole trip is in the past (it is possible, although inconsequential, to also provide updates for preceding stops). This option is most relevant for a trip that has completed ahead of schedule, but according to the schedule, the trip is still proceeding at the current time. Removing the updates for this trip could make the client assume that the trip is still proceeding. Note that the feed provider is allowed, but not required, to purge past updates - this is one case where this would be practically useful.