Determines whether the current fetch is incremental. Options include:

-FULL_DATASET: this feed update will overwrite all preceding realtime information for the feed. Thus this update is expected to provide a full snapshot of all known realtime information.

-DIFFERENTIAL: currently, this mode is unsupported and behavior is unspecified for feeds that use this mode. There are discussions on the GTFS Realtime mailing list around fully specifying the behavior of DIFFERENTIAL mode and the documentation will be updated when those discussions are finalized.

The trip_id from the GTFS feed that this selector refers to. Whether trip_id is required depends on the type of trip:

- Non-frequency-based trips: The trip_id field alone is enough to uniquely identify these trips. Note that non-frequency-based trips aren't defined in GTFS frequencies.txt.

- Frequency-based trips: The trip_id, start_time, and start_date fields are all required. Frequency-based trips are defined in GTFS frequencies.txt.

- Schedule-based trips: The trip_id field can be omitted only if the trip can be uniquely identified by a combination of the provided route_id, direction_id, start_time, and start_date fields. Note that scheduled-based trips aren't defined in GTFS frequencies.txt.

The initially scheduled start time of this trip instance. The field type Time defines the format of this field, for example 11:15:35 or 25:15:35. Whether the start_time field is required depends on the type of trip:

• The trip_id corresponds to a non-frequency-based trip: The start_time field needs to either be omitted or be equal to the value of departure_time in the GTFS feed's stop_times.txt file.

• The trip_id corresponds to a frequency-based trip: start_time is always required and must be specified for trip updates and vehicle positions. Frequency-based trips are defined in GTFS frequencies.txt.

◦ If the frequency-based trip corresponds to an exact_times=1 GTFS record: The start_time field must be some multiple, including zero, of headway_secs later than the frequencies.txt start_time for the corresponding time period.

◦ If the frequency-based trip corresponds to an exact_times=0 GTFS record: The start_time can be arbitrary, and it's initially expected to be the first departure of the trip. After it's established, the start_time of this frequency-based exact_times=0 trip is considered immutable, even if the first departure time changes. Any subsequent time changes can instead be reflected in a StopTimeUpdate message.

• The trip_id is omitted: start_time must be provided.

The start date of this trip instance in YYYYMMDD format. Whether start_date is required depends on the type of trip:

- Scheduled trips: start_date must be provided. This is to disambiguate trips that are so late that they collide with a scheduled trip on the next day. For example, suppose a train departs at 8:00 and 20:00 every day. If the train is 12 hours late, then there would be two distinct trips scheduled for the same time.

Note: This field is optional for scheduled trips in which such collisions are impossible. For example, this could happen if a service runs on an hourly schedule, and a vehicle that's one hour late isn't considered related to the schedule anymore.

- Frequency-based trips: start_date must be provided. Note that frequency-based trips are defined in the GTFS frequencies.txt file, while scheduled trips aren't.

- trip_id is omitted: start_date must be provided.

The current schedule deviation for the trip. The delay should only be specified when the prediction is given relative to some existing schedule in GTFS.

The delay (in seconds) can be positive (meaning that the vehicle is late) or negative (meaning that the vehicle is ahead of schedule). A 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.

Caution: this field is still experimental, and subject to change. It may be formally adopted in the future.