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 exact status of the vehicle with respect to the current stop. Ignored if current_stop_sequence is missing. Options include:

-INCOMING_AT: The vehicle is just about to arrive at the stop (on a stop display, the vehicle symbol typically flashes).

-STOPPED_AT: The vehicle is standing at the stop.

-IN_TRANSIT_TO: The vehicle has departed the previous stop and is in transit.

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.