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.

Cause of this alert. Options include:

-UNKNOWN_CAUSE

-OTHER_CAUSE

-TECHNICAL_PROBLEM

-STRIKE

-DEMONSTRATION

-ACCIDENT

-HOLIDAY

-WEATHER

-MAINTENANCE

-CONSTRUCTION

-POLICE_ACTIVITY

-MEDICAL_EMERGENCY

The effect of this problem on the affected entity. Options include:

-NO_SERVICE

-REDUCED_SERVICE

-SIGNIFICANT_DELAYS

-DETOUR

-ADDITIONAL_SERVICE

-MODIFIED_SERVICE

-OTHER_EFFECT

-UNKNOWN_EFFECT

-STOP_MOVED

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 direction_id from the GTFS feed trips.txt file, which indicates the direction of travel. If trip_id is omitted, direction_id must be provided.

Caution: This field is still experimental and subject to change. It might be formally adopted in the future.

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 relation between this trip and the static schedule. If TripDescriptor is provided in an Alert EntitySelector, the schedule_relationship field is ignored by consumers when they identify the matching trip instance. Options include:

-SCHEDULED: Trip that is running in accordance with its GTFS schedule, or is close enough to the scheduled trip to be associated with it.

-ADDED: An extra trip that was added in addition to a running schedule, for example, to replace a broken vehicle or to respond to sudden passenger load.

-UNSCHEDULED: A trip that is running with no schedule associated to it - this value is used to identify trips defined in GTFS frequencies.txt with exact_times = 0. It should not be used to describe trips not defined in GTFS frequencies.txt, or trips in GTFS frequencies.txt with exact_times = 1.

-CANCELED: A trip that existed in the schedule but was removed.