Struct gtfs_rt::TripUpdate
source · pub struct TripUpdate {
pub trip: TripDescriptor,
pub vehicle: Option<VehicleDescriptor>,
pub stop_time_update: Vec<StopTimeUpdate>,
pub timestamp: Option<u64>,
pub delay: Option<i32>,
pub trip_properties: Option<TripProperties>,
}
Expand description
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.
Fields§
§trip: TripDescriptor
The Trip that this message applies to. There can be at most one TripUpdate entity for each actual trip instance. If there is none, that means there is no prediction information available. It does not mean that the trip is progressing according to schedule.
vehicle: Option<VehicleDescriptor>
Additional information on the vehicle that is serving this trip.
stop_time_update: Vec<StopTimeUpdate>
Updates to StopTimes for the trip (both future, i.e., predictions, and in some cases, past ones, i.e., those that already happened). The updates must be sorted by stop_sequence, and apply for all the following stops of the trip up to the next specified one.
Example 1: For a trip with 20 stops, a StopTimeUpdate with arrival delay and departure delay of 0 for stop_sequence of the current stop means that the trip is exactly on time.
Example 2: For the same trip instance, 3 StopTimeUpdates are provided:
- delay of 5 min for stop_sequence 3
- delay of 1 min for stop_sequence 8
- delay of unspecified duration for stop_sequence 10 This will be interpreted as:
- stop_sequences 3,4,5,6,7 have delay of 5 min.
- stop_sequences 8,9 have delay of 1 min.
- stop_sequences 10,… have unknown delay.
timestamp: Option<u64>
The most recent moment at which the vehicle’s real-time progress was measured to estimate StopTimes in the future. When StopTimes in the past are provided, arrival/departure times may be earlier than this value. In POSIX time (i.e., the number of seconds since January 1st 1970 00:00:00 UTC).
delay: Option<i32>
The current schedule deviation for the trip. Delay should only be specified when the prediction is given relative to some existing schedule in GTFS.
Delay (in seconds) can be positive (meaning that the vehicle is late) or negative (meaning that the vehicle is ahead of schedule). Delay of 0 means that the vehicle is exactly on time.
Delay information in StopTimeUpdates take precedent of trip-level delay information, such that trip-level delay is only propagated until the next stop along the trip with a StopTimeUpdate delay value specified.
Feed providers are strongly encouraged to provide a TripUpdate.timestamp value indicating when the delay value was last updated, in order to evaluate the freshness of the data.
NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
trip_properties: Option<TripProperties>
Implementations§
Trait Implementations§
source§impl Clone for TripUpdate
impl Clone for TripUpdate
source§fn clone(&self) -> TripUpdate
fn clone(&self) -> TripUpdate
1.0.0 · source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moresource§impl Debug for TripUpdate
impl Debug for TripUpdate
source§impl Default for TripUpdate
impl Default for TripUpdate
source§impl Message for TripUpdate
impl Message for TripUpdate
source§fn encoded_len(&self) -> usize
fn encoded_len(&self) -> usize
source§fn encode<B>(&self, buf: &mut B) -> Result<(), EncodeError>
fn encode<B>(&self, buf: &mut B) -> Result<(), EncodeError>
source§fn encode_to_vec(&self) -> Vec<u8>where
Self: Sized,
fn encode_to_vec(&self) -> Vec<u8>where
Self: Sized,
source§fn encode_length_delimited<B>(&self, buf: &mut B) -> Result<(), EncodeError>
fn encode_length_delimited<B>(&self, buf: &mut B) -> Result<(), EncodeError>
source§fn encode_length_delimited_to_vec(&self) -> Vec<u8>where
Self: Sized,
fn encode_length_delimited_to_vec(&self) -> Vec<u8>where
Self: Sized,
source§fn decode<B>(buf: B) -> Result<Self, DecodeError>
fn decode<B>(buf: B) -> Result<Self, DecodeError>
source§fn decode_length_delimited<B>(buf: B) -> Result<Self, DecodeError>
fn decode_length_delimited<B>(buf: B) -> Result<Self, DecodeError>
source§fn merge<B>(&mut self, buf: B) -> Result<(), DecodeError>
fn merge<B>(&mut self, buf: B) -> Result<(), DecodeError>
self
. Read moresource§fn merge_length_delimited<B>(&mut self, buf: B) -> Result<(), DecodeError>
fn merge_length_delimited<B>(&mut self, buf: B) -> Result<(), DecodeError>
self
.source§impl PartialEq for TripUpdate
impl PartialEq for TripUpdate
source§fn eq(&self, other: &TripUpdate) -> bool
fn eq(&self, other: &TripUpdate) -> bool
self
and other
values to be equal, and is used
by ==
.