Proposal: Add TripUpdate.is_trip_finished

gtfs-realtime/proto/gtfs-realtime.proto

@@ -334,6 +334,17 @@ message TripUpdate {
   }
   optional TripProperties trip_properties = 6;
 
+  // When set to true, this field is a hint to the consumer that the producer has published the final TripUpdate for the
+  // trip identified in the TripDescriptor and no future TripUpdates with different values will be published. This
+  // allows consumers who have already received the final TripUpdate for this trip to ignore additional TripUpdates for
+  // the same trip in subsequent messages.
+  //
+  // Even if this field is set to true, producers should not drop a TripUpdate from a feed if it is prior to the
+  // scheduled arrival time for the last stop on the trip, as otherwise it will be concluded that there is no update for
+  // this trip.
+  // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+  optional bool is_trip_finished = 7 [default = false];
+
   // The extensions namespace allows 3rd-party developers to extend the
   // GTFS Realtime Specification in order to add and evaluate new features and
   // modifications to the spec.

gtfs-realtime/spec/en/reference.md

@@ -151,6 +151,7 @@ Note that the update can describe a trip that has already completed.To this end,
 | **timestamp** | [uint64](https://developers.google.com/protocol-buffers/docs/proto#scalar) | Optional | One | Moment at which the vehicle's real-time progress was measured. In POSIX time (i.e., the number of seconds since January 1st 1970 00:00:00 UTC). |
 | **delay** | [int32](https://developers.google.com/protocol-buffers/docs/proto#scalar) | Optional | One | The current schedule deviation for the trip. Delay should only be specified when the prediction is given relative to some existing schedule in GTFS.<br>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.<br>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.<br>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.<br>**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future.|
 | **trip_properties** | [TripProperties](#message-tripproperties) | Optional | One | Provides the updated properties for the trip. <br>**Caution:** this message is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **is_trip_finished** | [bool](https://developers.google.com/protocol-buffers/docs/proto#scalar) | Optional | One | When set to true, this field is a hint to the consumer that the producer has published the final TripUpdate for the trip identified in the TripDescriptor and no future TripUpdates with different values will be published. This allows consumers who have already received the final TripUpdate for this trip to ignore additional TripUpdates for the same trip in subsequent messages. <br> Even if this field is set to true, producers should not drop a TripUpdate from a feed if it is prior to the scheduled arrival time for the last stop on the trip, as otherwise it will be concluded that there is no update for this trip. <br>**Caution:** this message is still **experimental**, and subject to change. It may be formally adopted in the future. |
 
 ## _message_ StopTimeEvent