Struct GTFSRealtimeTripUpdate 

pub struct GTFSRealtimeTripUpdate {
    pub trip: GTFSRealtimeTripDescriptor,
    pub stop_time_update: Vec<GTFSRealtimeStopTimeUpdate>,
    pub vehicle: Option<GTFSRealtimeVehicleDescriptor>,
    pub timestamp: Option<u64>,
    pub delay: Option<i32>,
    pub trip_properties: Option<GTFSRealtimeTripProperties>,
}

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

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.

stop_time_update: Vec<GTFSRealtimeStopTimeUpdate>

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.

vehicle: Option<GTFSRealtimeVehicleDescriptor>

Additional information on the vehicle that is serving this trip.

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<GTFSRealtimeTripProperties>

Additional information about the trip.

Trait Implementations

impl Clone for GTFSRealtimeTripUpdate

fn clone(&self) -> GTFSRealtimeTripUpdate

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for GTFSRealtimeTripUpdate

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for GTFSRealtimeTripUpdate

fn default() -> GTFSRealtimeTripUpdate

Returns the “default value” for a type.

impl PartialEq for GTFSRealtimeTripUpdate

fn eq(&self, other: &GTFSRealtimeTripUpdate) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl ProtoRead for GTFSRealtimeTripUpdate

Read in the contents of the GTFSRealtimeTripUpdate

fn read(&mut self, tag: u64, pb: &mut Protobuf)

The read method is used to read a field from a protobuf message. The tag parameter is used to determine which field to read into the struct. The pbf parameter is used to read the data in the appropriate format.

impl StructuralPartialEq for GTFSRealtimeTripUpdate