diff --git a/docs/en/documentation/realtime/change-history/revision-history.md b/docs/en/documentation/realtime/change-history/revision-history.md
index 755b1409f..54833f670 100644
--- a/docs/en/documentation/realtime/change-history/revision-history.md
+++ b/docs/en/documentation/realtime/change-history/revision-history.md
@@ -2,6 +2,11 @@
### Revision History
+#### May 2025
+
+* Deprecates schedule_relationship `ADDED` in favour of `NEW` and adds `REPLACEMENT`. See [discussion](https://github.com/google/transit/pull/504).
+* Further clarifications to trip modifications. See [discussion](https://github.com/google/transit/pull/542).
+
#### December 2024
* Added new string field that matches feed_info.feed_version from the GTFS Schedule feed that the realtime data is based on. See [discussion](https://github.com/google/transit/pull/434).
diff --git a/docs/en/documentation/realtime/examples/migration-duplicated.md b/docs/en/documentation/realtime/examples/migration-duplicated.md
index 582e7e84d..f9f4619ea 100644
--- a/docs/en/documentation/realtime/examples/migration-duplicated.md
+++ b/docs/en/documentation/realtime/examples/migration-duplicated.md
@@ -1,13 +1,77 @@
-## Migration Guide - Transition from ADDED to DUPLICATED trips
+## Migration Guide - Transition from ADDED to NEW or DUPLICATED trips
+
+The GTFS-realtime `trip.schedule_relationship` of `NEW` represents a new trip that runs on a schedule unrelated to any existing scheduled trip.
The GTFS-realtime `trip.schedule_relationship` of `DUPLICATED` represents a new trip that is the same as an existing scheduled trip except for service start date and time.
-This migration guide defines how existing producers and consumers that were using the `ADDED` enumeration to represent duplicated trips should transition to the `DUPLICATED` enumeration. The goal is to minimize disruption to producers and consumers during the transition.
+This migration guide defines how existing producers and consumers that were using the `ADDED` enumeration should transition to either the `NEW` and the `DUPLICATED` enumeration. The goal is to minimize disruption to producers and consumers during the transition.
+
+*If you are a producer or consumer that has **not** used the `ADDED` enumeration, no action is required - you can produce/consume `NEW` and/or `DUPLICATED` trips without producing/consuming any `ADDED` entities.*
-*If you are a producer or consumer that has **not** used the `ADDED` enumeration to describe duplicated trips, no action is required - you can produce/consume `DUPLICATED` trips without producing/consuming any `ADDED` entities.*
+For a full history of the `NEW` enumeration, see the [`NEW` and `REPLACEMENT` proposal on GitHub](https://github.com/google/transit/pull/504).
For a full history of the `DUPLICATED` enumeration, see the [`DUPLICATED` proposal on GitHub](https://github.com/google/transit/pull/221).
+### Which one to migrate to
+
+Both `NEW` and `DUPLICATED` enumeration are used to specify a trip which was not originally scheduled to run in the GTFS static.
+
+Use `NEW` if your trip cannot be described using any scheduled trips as a template. For example, if the trip calls at different stops from the regular trips of the route, or if the extra trip is pickup only at the beginning of the route despite that the regular trips allow both pickup and drop off at all stops.
+
+Use `DUPLICATED` if your trip is a copy of a scheduled trip, which may run at the same, or at different times of the original scheduled trip.
+
+### Using ADDED and NEW entities in the same feed
+
+If you are a producer who has been using the `ADDED` enumeration to specify trips which are unrelated to the schedule, to avoid disruption to existing consumers it is recommended that you continue to produce `ADDED` entities for these trips but also add `NEW` entities for the same trip.
+
+However, to prevent consumers from accidentally adding the same trip twice, the entities referencing the same trip **must** be linked using the same `trip_id`, `route_id` and `start_date`.
+In addition, the contents of the `stop_time_update` must also be the same as well.
+
+#### Producers
+
+~~~
+entity {
+ id: "ei0"
+ trip_update {
+ trip: {
+ trip_id: "1" // <-- a trip_id not found in the static GTFS
+ route_id: "A"
+ schedule_relationship: ADDED
+ start_date: "20200821" // <-- New trip date
+ start_time: "11:30:00" // <-- New trip time
+ }
+ stop_time_update {
+ ... // The full list of the calling points of the trip
+ }
+ }
+}
+
+entity {
+ id: "ei10"
+ trip_update {
+ trip: {
+ trip_id: "1" // <-- The same trip_id as the above
+ route_id: "A" // <-- The same route_id as the above
+ schedule_relationship: NEW
+ start_date: "20200821" // <-- The same date as the above
+ start_time: "11:30:00" // <-- The same time as the above
+ }
+ stop_time_update {
+ ... // <-- The same content as the above
+ }
+ }
+}
+~~~
+
+It is suggested that you notify existing consumers (e.g., via a developer mailing list) that the use of `ADDED` is being deprecated by a set deadline and that consumers should start consuming the `NEW` trips instead. The above strategy being used to match `ADDED` and `NEW` trip entities should also be mentioned and a link to this migration guide should be included. After the deadline passes, you can remove the `ADDED` entities from your feed and publish only the `NEW` entities for newly-added trips.
+
+#### Consumers
+
+As mentioned above, producers will transition from `ADDED` to `NEW` enumerations by initially publishing two entities for each new trip using the same `trip_id`.
+
+Therefore, when a consumer implements support for `NEW` trips, it is important that consumers ignore any `ADDED` trips that have the same `trip_id` as a `NEW` trip `trip_id`.
+
+
### Using ADDED and DUPLICATED entities in same feed
#### Producers
@@ -93,7 +157,7 @@ entity {
}
~~~
-It is suggested that you notify existing consumers (e.g., via a developer mailing list) that the use of `ADDED` for duplicated trips is being deprecated by a set deadline and that consumers should start consuming the `DUPLICATED` trips instead. The above strategy being used to match `ADDED` and `DUPLICATED` trip entities should also be mentioned and a link to this migration guide should be included. After the deadline passes, you can remove the `ADDED` entities from your feed and publish only the `DUPLICATED` entities for duplicated trips.
+It is suggested that you notify existing consumers (e.g., via a developer mailing list) that the use of `ADDED` is being deprecated by a set deadline and that consumers should start consuming the `DUPLICATED` trips instead. The above strategy being used to match `ADDED` and `DUPLICATED` trip entities should also be mentioned and a link to this migration guide should be included. After the deadline passes, you can remove the `ADDED` entities from your feed and publish only the `DUPLICATED` entities for duplicated trips.
#### Consumers
diff --git a/docs/en/documentation/realtime/feed-entities/trip-updates.md b/docs/en/documentation/realtime/feed-entities/trip-updates.md
index 07a9365c7..f81080e26 100644
--- a/docs/en/documentation/realtime/feed-entities/trip-updates.md
+++ b/docs/en/documentation/realtime/feed-entities/trip-updates.md
@@ -13,7 +13,7 @@ If a vehicle is serving multiple trips within the same block (for more informati
## StopTimeUpdate
-A trip update consists of one or more updates to vehicle stop times, which are referred to as [StopTimeUpdates](../../reference/#message-stoptimeupdate). These can be supplied for past and future stop times. You are allowed, but not required, to drop past stop times. Producers should not drop a past `StopTimeUpdate` if it refers to a stop with a scheduled arrival time in the future for the given trip (i.e. the vehicle has passed the stop ahead of schedule), as otherwise it will be concluded that there is no update for this stop.
+A trip update consists of one or more updates to vehicle stop times, which are referred to as [StopTimeUpdates](../../reference/#message-stoptimeupdate). These can be supplied for past and future stop times. You are allowed, but not required, to drop past stop times, unless the trip is a new or replacement trip not found in the GTFS static. Producers should not drop a past `StopTimeUpdate` if it refers to a stop with a scheduled arrival time in the future for the given trip (i.e. the vehicle has passed the stop ahead of schedule), as otherwise it will be concluded that there is no update for this stop.
For example, if the following data appears in the GTFS-rt feed:
diff --git a/docs/en/documentation/realtime/gtfs-realtime.proto b/docs/en/documentation/realtime/gtfs-realtime.proto
index 34a8a20ab..e050fc19f 100644
--- a/docs/en/documentation/realtime/gtfs-realtime.proto
+++ b/docs/en/documentation/realtime/gtfs-realtime.proto
@@ -195,6 +195,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -277,6 +284,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -374,16 +407,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -798,14 +838,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -814,8 +850,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -824,7 +861,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -844,6 +884,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -869,8 +913,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1051,7 +1095,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1139,10 +1183,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1200,7 +1245,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
diff --git a/docs/en/documentation/realtime/proto.md b/docs/en/documentation/realtime/proto.md
index 93dd4eca5..8d75da9b6 100644
--- a/docs/en/documentation/realtime/proto.md
+++ b/docs/en/documentation/realtime/proto.md
@@ -199,6 +199,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -281,6 +288,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -378,16 +411,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -802,14 +842,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -818,8 +854,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -828,7 +865,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -848,6 +888,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -873,8 +917,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1055,7 +1099,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1143,10 +1187,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1204,7 +1249,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
diff --git a/docs/en/documentation/realtime/realtime-best-practices.md b/docs/en/documentation/realtime/realtime-best-practices.md
index 47cbf1bd2..7d5b86d7f 100644
--- a/docs/en/documentation/realtime/realtime-best-practices.md
+++ b/docs/en/documentation/realtime/realtime-best-practices.md
@@ -48,7 +48,7 @@ All entities should only be removed from a GTFS Realtime feed when they are no l
General guidelines for trip cancellations:
* When canceling trips over a number of days, producers should provide TripUpdates referencing the given `trip_ids` and `start_dates` as `CANCELED` as well as an Alert with `NO_SERVICE` referencing the same `trip_ids` and `TimeRange` that can be shown to riders explaining the cancellation (e.g., detour).
-* If no stops in a trip will be visited, the trip should be `CANCELED` instead of having all `stop_time_updates` being marked as `SKIPPED`.
+* If no stops in a trip will be visited, the trip should be `CANCELED` instead of having all `stop_time_updates` being marked as `SKIPPED`, unless the trip was a `NEW` or `DUPLICATED` trip and was subsequently canceled.
| Field Name | Recommendation |
| --- | --- |
@@ -69,7 +69,13 @@ For example, a `VehiclePosition` entity has `vehicle_id:A` and `trip_id:4`, then
| Field Name | Recommendation |
| --- | --- |
-| `schedule_relationship` | The behavior of `ADDED` trips are unspecified and the use of this enumeration is not recommended. |
+| `schedule_relationship` | The behavior of `ADDED` trips are unspecified and the use of this enumeration is not recommended.
If the trip is not scheduled to run originally, use `NEW` if it doesn't follow the stopping pattern of an existing trip, or `DUPLICATED` if it is a copy of an existing trip.
If the trip runs on a modified schedule or stops, but can be associated to an original scheduled trip in the GTFS static, use `REPLACEMENT` and specify the full list of stop times for the modified trip. |
+
+### TripProperties
+
+| Field Name | Recommendation |
+| --- | --- |
+| `trip_headsign` | Should always be provided for a trip with `TripDescriptor.schedule_relationship` = `NEW`, and provided for a trip with `TripDescriptor.schedule_relationship` = `REPLACEMENT` if the trip is diverted. |
### VehicleDescriptor
@@ -97,6 +103,7 @@ For example, a `VehiclePosition` entity has `vehicle_id:A` and `trip_id:4`, then
| Field Name | Recommendation |
| --- | --- |
| `delay` | If only `delay` is provided in a `stop_time_update` `arrival` or `departure` (and not `time`), then the GTFS [`stop_times.txt`](../../schedule/reference/#stop_timestxt) should contain `arrival_times` and/or `departure_times` for these corresponding stops. A `delay` value in the realtime feed is meaningless unless you have a clock time to add it to in the GTFS `stop_times.txt` file. |
+| `scheduled_time` | If the trip is a new or replacement trip, and the trip will run according to a schedule (which can be a modified schedule in case of a replacement trip), `scheduled_time` should be provided for all timepoints. If a duplicated trip runs have different run or dwell times compared to the original, `scheduled_time` can also be used to specify them. |
### VehiclePosition
diff --git a/docs/en/documentation/realtime/reference.md b/docs/en/documentation/realtime/reference.md
index 4795a6693..edebf9ded 100644
--- a/docs/en/documentation/realtime/reference.md
+++ b/docs/en/documentation/realtime/reference.md
@@ -14,6 +14,7 @@ The following values are used in the *Required* field:
* **Required**: This field must be provided by a GTFS-realtime feed producer.
* **Conditionally required**: This field is required under certain conditions, which are outlined in the field *Description*. Outside of these conditions, the field is optional.
+* **Conditionally forbidden**: This field is forbidden under certain conditions, which are outlined in the field *Description*. Outside of these conditions, the field is optional.
* **Optional**: This field is optional and is not required to be implemented by producers. However, if the data is available in the underlying automatic vehicle location systems (e.g., VehiclePosition `timestamp`) it is recommended that producers provide these optional fields when possible.
*Note that semantic requirements were not defined in GTFS-realtime version 1.0, and therefore feeds with `gtfs_realtime_version` of `1` may not meet these requirements (see [the proposal for semantic requirements](https://github.com/google/transit/pull/64) for details).*
@@ -150,6 +151,7 @@ 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 has been added or removed with regard to schedule.
+* A trip that replaces an existing trip in static GTFS.
* A new trip that is a copy of an existing trip in static GTFS. It will run at the service date and time specified in TripProperties.
The updates can be for future, predicted arrival/departure events, or for past events that already occurred. In most cases information about past events is a measured value thus its uncertainty value is recommended to be 0\. Although there could be cases when this does not hold so it is allowed to have uncertainty value different from 0 for past events. If an update's uncertainty is not 0, either the update is an approximate prediction for a trip that has not completed or the measurement is not precise or the update was a prediction for the past that has not been verified after the event occurred.
@@ -167,17 +169,18 @@ Note that the update can describe a trip that has already completed.To this end,
|------------------|------------|----------------|-------------------|-------------------|
| **trip** | [TripDescriptor](#message-tripdescriptor) | Required | One | 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. |
| **vehicle** | [VehicleDescriptor](#message-vehicledescriptor) | Optional | One | Additional information on the vehicle that is serving this trip. |
-| **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) | Conditionally required | Many | 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 stop_time_update. At least one stop_time_update must be provided for the trip unless the trip.schedule_relationship is CANCELED, DELETED, or DUPLICATED. If the trip is canceled or deleted, no stop_time_updates need to be provided. If stop_time_updates are provided for a canceled or deleted trip then the trip.schedule_relationship takes precedence over any stop_time_updates and their associated schedule_relationship. If the trip is duplicated, stop_time_updates may be provided to indicate real-time information for the new trip. |
+| **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) | Conditionally required | Many | 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 stop_time_update.
If trip.schedule_relationship is SCHEDULED or UNSCHEDULED, at least one stop_time_update must be provided for the trip.
If trip.schedule_relationship is NEW or REPLACEMENT, stop_time_updates must be provided for all stops in the new or replacement trip, including stops with times in the past, and the stop times in the static GTFS are not used.
If the trip is canceled or deleted, no stop_time_updates need to be provided. If stop_time_updates are provided for a canceled or deleted trip then the trip.schedule_relationship takes precedence over any stop_time_updates and their associated schedule_relationship. If the trip is duplicated, stop_time_updates may be provided to indicate real-time information for the new trip. |
| **timestamp** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | 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** | [int32](https://protobuf.dev/programming-guides/proto2/#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.
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.
**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.
**Caution:** this message is still **experimental**, and subject to change. It may be formally adopted in the future. |
### _message_ StopTimeEvent
-Timing information for a single predicted event (either arrival or departure). Timing consists of delay and/or estimated time, and uncertainty.
+Timing information for a single predicted event (either arrival or departure). Timing consists of delay and/or estimated time, and uncertainty. A scheduled time can also be added for NEW, REPLACEMENT, or DUPLICATED trips.
* delay should be used when the prediction is given relative to some existing schedule in GTFS.
-* time should be given whether there is a predicted schedule or not. If both time and delay are specified, time will take precedence (although normally, time, if given for a scheduled trip, should be equal to scheduled time in GTFS + delay).
+* time should be given whether there is a predicted schedule or not, and must be given for new or replacement trips. If both time and delay are specified, time will take precedence (although normally, time, if given for a scheduled trip, should be equal to scheduled time in GTFS + delay).
+* scheduled time may be given if the trip is a new, replacement or duplicated trip.
Uncertainty applies equally to both time and delay. The uncertainty roughly specifies the expected error in true delay (but note, we don't yet define its precise statistical meaning). It's possible for the uncertainty to be 0, for example for trains that are driven under computer timing control.
@@ -185,25 +188,28 @@ Uncertainty applies equally to both time and delay. The uncertainty roughly spec
| _**Field Name**_ | _**Type**_ | _**Required**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|----------------|-------------------|-------------------|
-| **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | 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. Either delay or time must be provided within a StopTimeEvent - both fields cannot be empty. |
-| **time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Event as absolute time. In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC). Either delay or time must be provided within a StopTimeEvent - both fields cannot be empty. |
-| **uncertainty** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | If uncertainty is omitted, it is interpreted as unknown. To specify a completely certain prediction, set its uncertainty to 0. |
+| **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | 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.
**Forbidden** if StopTimeUpdate.schedule_relationship is NO_DATA.
**Required** otherwise if time is not given. |
+| **time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Estimated or actual event as absolute time. In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC).
**Forbidden** if StopTimeUpdate.schedule_relationship is NO_DATA.
**Required** otherwise if delay is not given. |
+| **scheduled_time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally forbidden | One | Scheduled time. In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC).
**Optional** if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, **forbidden** otherwise. |
+| **uncertainty** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | If uncertainty is omitted, it is interpreted as unknown. To specify a completely certain prediction, set its uncertainty to 0.
**Forbidden** if StopTimeUpdate.schedule_relationship is NO_DATA. |
### _message_ StopTimeUpdate
Realtime update for arrival and/or departure events for a given stop on a trip. Please also refer to the general discussion of stop time updates in the [TripDescriptor](#message-tripdescriptor) and [trip updates entities](../../../documentation/realtime/feed-entities/trip-updates) documentation.
-Updates can be supplied for both past and future events. The producer is allowed, although not required, to drop past events.
+Updates can be supplied for both past and future events. The producer is allowed, although not required, to drop past events, unless if `TripUpdate.schedule_relationship` is NEW or REPLACEMENT, in such case past stops must not be dropped as they define the trip the vehicle is on, until the whole trip has been finished.
The update is linked to a specific stop either through stop_sequence or stop_id, so one of these fields must necessarily be set. If the same stop_id is visited more than once in a trip, then stop_sequence should be provided in all StopTimeUpdates for that stop_id on that trip.
+In new or replacement trips, updates are used to specify the stops visited by the trip without referring to an existing trip in the GTFS Static. In such trips, `stop_id`, `stop_sequence`, `departure` and `arrival` must all be set.
+
**Fields**
| _**Field Name**_ | _**Type**_ | _**Required**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|----------------|-------------------|-------------------|
-| **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Must be the same as in stop_times.txt in the corresponding GTFS feed. Either stop_sequence or stop_id must be provided within a StopTimeUpdate - both fields cannot be empty. stop_sequence is required for trips that visit the same stop_id more than once (e.g., a loop) to disambiguate which stop the prediction is for. If `StopTimeProperties.assigned_stop_id` is populated, then `stop_sequence` must be populated. |
-| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Must be the same as in stops.txt in the corresponding GTFS feed. Either stop_sequence or stop_id must be provided within a StopTimeUpdate - both fields cannot be empty. If `StopTimeProperties.assigned_stop_id` is populated, it is preferred to omit `stop_id` and use only `stop_sequence`. If `StopTimeProperties.assigned_stop_id` and `stop_id` are populated, `stop_id` must match `assigned_stop_id`. |
-| **arrival** | [StopTimeEvent](#message-stoptimeevent) | Conditionally required | One | If schedule_relationship is empty or SCHEDULED, either arrival or departure must be provided within a StopTimeUpdate - both fields cannot be empty. arrival and departure may both be empty when schedule_relationship is SKIPPED. If schedule_relationship is NO_DATA, arrival and departure must be empty. |
-| **departure** | [StopTimeEvent](#message-stoptimeevent) | Conditionally required | One | If schedule_relationship is empty or SCHEDULED, either arrival or departure must be provided within a StopTimeUpdate - both fields cannot be empty. arrival and departure may both be empty when schedule_relationship is SKIPPED. If schedule_relationship is NO_DATA, arrival and departure must be empty. |
+| **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Must be the same as in stop_times.txt in the corresponding GTFS feed. Either stop_sequence or stop_id must be provided within a StopTimeUpdate - both fields cannot be empty. stop_sequence is required for trips that visit the same stop_id more than once (e.g., a loop) to disambiguate which stop the prediction is for. If `StopTimeProperties.assigned_stop_id` is populated, then `stop_sequence` must be populated. **Required** if `TripUpdate.schedule_relationship` is NEW or REPLACEMENT, and the value must be increasing along the trip. |
+| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Must be the same as in stops.txt in the corresponding GTFS feed. Either stop_sequence or stop_id must be provided within a StopTimeUpdate - both fields cannot be empty. If `StopTimeProperties.assigned_stop_id` is populated, it is preferred to omit `stop_id` and use only `stop_sequence`. If `StopTimeProperties.assigned_stop_id` and `stop_id` are populated, `stop_id` must match `assigned_stop_id`. **Required** if `TripUpdate.schedule_relationship` is NEW or REPLACEMENT. |
+| **arrival** | [StopTimeEvent](#message-stoptimeevent) | Conditionally required | One | If schedule_relationship is empty or SCHEDULED, either arrival or departure must be provided within a StopTimeUpdate - both fields cannot be empty. arrival and departure may both be empty when schedule_relationship is SKIPPED. **Required** if `TripUpdate.schedule_relationship` is NEW or REPLACEMENT. |
+| **departure** | [StopTimeEvent](#message-stoptimeevent) | Conditionally required | One | If schedule_relationship is empty or SCHEDULED, either arrival or departure must be provided within a StopTimeUpdate - both fields cannot be empty. arrival and departure may both be empty when schedule_relationship is SKIPPED. **Required** if `TripUpdate.schedule_relationship` is NEW or REPLACEMENT. |
| **departure_occupancy_status** | [OccupancyStatus](#enum-occupancystatus) | Optional | One | The predicted state of passenger occupancy for the vehicle immediately after departure from the given stop. If provided, stop_sequence must be provided. To provide departure_occupancy_status without providing any real-time arrival or departure predictions, populate this field and set StopTimeUpdate.schedule_relationship = NO_DATA.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship) | Optional | One | The default relationship is SCHEDULED. |
| **stop_time_properties** | [StopTimeProperties](#message-stoptimeproperties) | Optional | One | Realtime updates for certain properties defined within GTFS stop_times.txt
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
@@ -218,7 +224,7 @@ The relation between this StopTime and the static schedule.
|-------------|---------------|
| **SCHEDULED** | The vehicle is proceeding in accordance with its static schedule of stops, although not necessarily according to the times of the schedule. This is the **default** behavior. At least one of arrival and departure must be provided. Frequency-based trips (GTFS frequencies.txt with exact_times = 0) should not have a SCHEDULED value and should use UNSCHEDULED instead. |
| **SKIPPED** | The stop is skipped, i.e., the vehicle will not stop at this stop. Arrival and departure are optional. When set `SKIPPED` is not propagated to subsequent stops in the same trip (i.e., the vehicle will stop at subsequent stops in the trip unless those stops also have a `stop_time_update` with `schedule_relationship: SKIPPED`). Delay from a previous stop in the trip *does* propagate over the `SKIPPED` stop. In other words, if a `stop_time_update` with an `arrival` or `departure` prediction is not set for a stop after the `SKIPPED` stop, the prediction upstream of the `SKIPPED` stop will be propagated to the stop after the `SKIPPED` stop and subsequent stops in the trip until a `stop_time_update` for a subsequent stop is provided. |
-| **NO_DATA** | No data is given for this stop. It indicates that there is no realtime timing information available. When set NO_DATA is propagated through subsequent stops so this is the recommended way of specifying from which stop you do not have realtime timing information. When NO_DATA is set neither arrival nor departure should be supplied. |
+| **NO_DATA** | No real-time data is given for this stop. It indicates that there is no realtime timing information available. When set NO_DATA is propagated through subsequent stops so this is the recommended way of specifying from which stop you do not have realtime timing information. When NO_DATA is set, arrival or departure must not be supplied, unless `TripDescriptor.schedule_relationship` is `NEW` or `REPLACEMENT`, in such case only the scheduled time, but not predictions, must be supplied. When `TripDescriptor.schedule_relationship` is `NEW` or `REPLACEMENT`, `arrival` and `departure` must still be given with scheduled times, as the StopTimeUpdate defines the stop list of the trip. In this case it indicates that the schedule is unrelated to the static GTFS, but real-time prediction is not available yet. |
| **UNSCHEDULED** | The vehicle is operating a frequency-based trip (GTFS frequencies.txt with exact_times = 0). This value should not be used for trips that are not defined in GTFS frequencies.txt, or trips in GTFS frequencies.txt with exact_times = 1. Trips containing `stop_time_updates` with `schedule_relationship: UNSCHEDULED` must also set the TripDescriptor `schedule_relationship: UNSCHEDULED`
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future.
### _message_ StopTimeProperties
@@ -232,6 +238,20 @@ Realtime update for certain properties defined within GTFS stop_times.txt.
| _**Field Name**_ | _**Type**_ | _**Required**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|----------------|-------------------|-------------------|
| **assigned_stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | Supports real-time stop assignments. Refers to a `stop_id` defined in the GTFS `stops.txt`.
The new `assigned_stop_id` should not result in a significantly different trip experience for the end user than the `stop_id` defined in GTFS `stop_times.txt`. In other words, the end user should not view this new `stop_id` as an "unusual change" if the new stop was presented within an app without any additional context. For example, this field is intended to be used for platform assignments by using a `stop_id` that belongs to the same station as the stop originally defined in GTFS `stop_times.txt`.
To assign a stop without providing any real-time arrival or departure predictions, populate this field and set `StopTimeUpdate.schedule_relationship = NO_DATA`.
If this field is populated, `StopTimeUpdate.stop_sequence` must be populated and `StopTimeUpdate.stop_id` should not be populated. Stop assignments should be reflected in other GTFS-realtime fields as well (e.g., `VehiclePosition.stop_id`).
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **stop_headsign** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | The updated headsign of the vehicle at the stop.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **drop_off_type** | [DropOffPickupType](#enum-dropoffpickuptype) | Optional | One | The updated drop off of the vehicle at the stop.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **pickup_type** | [DropOffPickupType](#enum-dropoffpickuptype) | Optional | One | The updated pickup of the vehicle at the stop.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+
+## _enum_ DropOffPickupType
+
+**Values**
+
+| _**Value**_ | _**Comment**_ |
+|----------------------------|--------------------------------------------------------|
+| **REGULAR** | Regularly scheduled pickup/dropoff. |
+| **NONE** | No pickup/dropoff available. |
+| **PHONE_AGENCY** | Must phone agency to arrange pickup/dropoff. |
+| **COORDINATE_WITH_DRIVER** | Must coordinate with driver to arrange pickup/dropoff. |
### _message_ TripProperties
@@ -246,7 +266,9 @@ Defines updated properties of the trip
| **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Defines the identifier of a new trip that is a duplicate of an existing trip defined in (CSV) GTFS trips.txt but will start at a different service date and/or time (defined using `TripProperties.start_date` and `TripProperties.start_time`). See definition of `trips.trip_id` in (CSV) GTFS. Its value must be different than the ones used in the (CSV) GTFS. This field is required if `schedule_relationship` is `DUPLICATED`, otherwise this field must not be populated and will be ignored by consumers.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
| **start_date** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Service date on which the duplicated trip will be run. Must be provided in YYYYMMDD format. This field is required if `schedule_relationship` is `DUPLICATED`, otherwise this field must not be populated and will be ignored by consumers.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | Defines the departure start time of the trip when it’s duplicated. See definition of `stop_times.departure_time` in (CSV) GTFS. Scheduled arrival and departure times for the duplicated trip are calculated based on the offset between the original trip `departure_time` and this field. For example, if a GTFS trip has stop A with a `departure_time` of `10:00:00` and stop B with `departure_time` of `10:01:00`, and this field is populated with the value of `10:30:00`, stop B on the duplicated trip will have a scheduled `departure_time` of `10:31:00`. Real-time prediction `delay` values are applied to this calculated schedule time to determine the predicted time. For example, if a departure `delay` of `30` is provided for stop B, then the predicted departure time is `10:31:30`. Real-time prediction `time` values do not have any offset applied to them and indicate the predicted time as provided. For example, if a departure `time` representing 10:31:30 is provided for stop B, then the predicted departure time is `10:31:30`.This field is required if `schedule_relationship` is `DUPLICATED`, otherwise this field must not be populated and will be ignored by consumers.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
-| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | Specifies the shape of the vehicle travel path for this trip when it differs from the original. Refers to a shape defined in the (CSV) GTFS or a new shape entity in a real-time feed. See definition of `trips.shape_id` in (CSV) GTFS.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **trip_headsign** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | Specifies the headsign for this trip when it differs from the original.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **trip_short_name** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | Specifies the name for this trip when it differs from the original.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of `trips.shape_id` in (CSV) GTFS.
If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS. If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
### _message_ VehiclePosition
@@ -441,7 +463,7 @@ A geographic position of a vehicle.
### _message_ TripDescriptor
-A descriptor that identifies a single instance of a GTFS trip.
+A descriptor that identifies a single instance of a GTFS trip, unless `schedule_relationship` is `NEW`, in such case, it specifies a new instance of trip to be added.
To specify a single trip instance, in many cases a `trip_id` by itself is sufficient. However, the following cases require additional information to resolve to a single trip instance:
@@ -457,12 +479,14 @@ Note that if the trip_id is not known, then station sequence ids in TripUpdate a
TripDescriptor.route_id cannot be used within an Alert EntitySelector to specify a route-wide alert that affects all trips for a route - use EntitySelector.route_id instead.
+If `schedule_relationship` is `NEW`, `trip_id` must be set to a value not listed in the GTFS feed, and `route_id` must be set to a value listed in `routes.txt` in the GTFS static, to associate the trip to a route. `start_date` should be set, and `direction_id` may be set for the new trip.
+
**Fields**
| _**Field Name**_ | _**Type**_ | _**Required**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|----------------|-------------------|-------------------|
-| **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | The trip_id from the GTFS feed that this selector refers to. For non frequency-based trips (trips not defined in GTFS frequencies.txt), this field is enough to uniquely identify the trip. For frequency-based trips defined in GTFS frequencies.txt, trip_id, start_time, and start_date are all required. For scheduled-based trips (trips not defined in GTFS frequencies.txt), trip_id can only be omitted if the trip can be uniquely identified by a combination of route_id, direction_id, start_time, and start_date, and all those fields are provided. When schedule_relationship is DUPLICATED within a TripUpdate, the trip_id identifies the trip from static GTFS to be duplicated. When schedule_relationship is DUPLICATED within a VehiclePosition, the trip_id identifies the new duplicate trip and must contain the value for the corresponding TripUpdate.TripProperties.trip_id. |
-| **route_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | The route_id from the GTFS that this selector refers to. If trip_id is omitted, route_id, direction_id, start_time, and schedule_relationship=SCHEDULED must all be set to identify a trip instance. TripDescriptor.route_id should not be used within an Alert EntitySelector to specify a route-wide alert that affects all trips for a route - use EntitySelector.route_id instead. |
+| **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | The trip_id from the GTFS feed that this selector refers to. For non frequency-based trips (trips not defined in GTFS frequencies.txt), this field is enough to uniquely identify the trip. For frequency-based trips defined in GTFS frequencies.txt, trip_id, start_time, and start_date are all required. For scheduled-based trips (trips not defined in GTFS frequencies.txt), trip_id can only be omitted if the trip can be uniquely identified by a combination of route_id, direction_id, start_time, and start_date, and all those fields are provided. When schedule_relationship is NEW, it must be specified with a unique value not defined in the GTFS static. When schedule_relationship is REPLACEMENT, the trip_id identifies the trip from static GTFS to be replaced. When schedule_relationship is DUPLICATED within a TripUpdate, the trip_id identifies the trip from static GTFS to be duplicated. When schedule_relationship is DUPLICATED within a VehiclePosition, the trip_id identifies the new duplicate trip and must contain the value for the corresponding TripUpdate.TripProperties.trip_id. |
+| **route_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | The route_id from the GTFS that this selector refers to. If trip_id is omitted, route_id, direction_id, start_time, and schedule_relationship=SCHEDULED must all be set to identify a trip instance. TripDescriptor.route_id should not be used within an Alert EntitySelector to specify a route-wide alert that affects all trips for a route - use EntitySelector.route_id instead. When schedule_relationship is NEW, route_id must be specified for route which the new trip belongs to. |
| **direction_id** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | The direction_id from the GTFS feed trips.txt file, indicating the direction of travel for trips this selector refers to. If trip_id is omitted, direction_id must be provided.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future.
|
| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | The initially scheduled start time of this trip instance. When the trip_id corresponds to a non-frequency-based trip, this field should either be omitted or be equal to the value in the GTFS feed. When the trip_id correponds to a frequency-based trip defined in GTFS frequencies.txt, start_time is required and must be specified for trip updates and vehicle positions. If the trip corresponds to exact_times=1 GTFS record, then start_time must be some multiple (including zero) of headway_secs later than frequencies.txt start_time for the corresponding time period. If the trip corresponds to exact_times=0, then its start_time may be arbitrary, and is initially expected to be the first departure of the trip. Once established, the start_time of this frequency-based exact_times=0 trip should be considered immutable, even if the first departure time changes -- that time change may instead be reflected in a StopTimeUpdate. If trip_id is omitted, start_time must be provided. Format and semantics of the field is same as that of GTFS/frequencies.txt/start_time, e.g., 11:15:35 or 25:15:35. |
| **start_date** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionally required | One | The start date of this trip instance in YYYYMMDD format. For scheduled trips (trips not defined in GTFS frequencies.txt), this field must be provided to disambiguate trips that are so late as to collide with a scheduled trip on a next day. For example, for a train that departs 8:00 and 20:00 every day, and is 12 hours late, there would be two distinct trips on the same time. This field can be provided but is not mandatory for schedules in which such collisions are impossible - for example, a service running on hourly schedule where a vehicle that is one hour late is not considered to be related to schedule anymore. This field is required for frequency-based trips defined in GTFS frequencies.txt. If trip_id is omitted, start_date must be provided. |
@@ -471,17 +495,19 @@ TripDescriptor.route_id cannot be used within an Alert EntitySelector to specify
### _enum_ ScheduleRelationship
-The relation between this trip and the static schedule. If a trip is done in accordance with temporary schedule, not reflected in GTFS, then it shouldn't be marked as SCHEDULED, but marked as ADDED.
+The relation between this trip and the static schedule. If a new trip is done in accordance with temporary schedule, not reflected in GTFS, then it shouldn't be marked as SCHEDULED, but marked as NEW. If a trip is done in accordance with a modified schedule, not reflected in GTFS, then it shouldn't be marked as SCHEDULED, but marked as REPLACEMENT.
**Values**
| _**Value**_ | _**Comment**_ |
|-------------|---------------|
| **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. *NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221) [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the documentation will be updated when those discussions are finalized.* |
+| **ADDED** | *NOTE: This value has been deprecated as the behavior was unspecified. Use **DUPLICATED** for an extra trip that is the same as a scheduled trip except the start date or time, or **NEW** for an extra trip that is unrelated to an existing trip.* |
| **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. Trips with `schedule_relationship: UNSCHEDULED` must also set all StopTimeUpdates `schedule_relationship: UNSCHEDULED`|
| **CANCELED** | A trip that existed in the schedule but was removed. |
+| **REPLACEMENT** | A trip that replaces an existing scheduled trip, for example, with a changed schedule or a diverted routing. The complete journey of the replacement trip must be specified via `StopTimeUpdate`s, and the original schedule from the GTFS static isn't used for the replaced instance.
`REPLACEMENT` can be used if the trip is operating on a revised schedule, but must not be used to communicate real-time schedule deviations (predictions) if the vehicle is aimed to follow the schedule listed in `stop_times.txt` the static GTFS.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
| **DUPLICATED** | A new trip that is the same as an existing scheduled trip except for service start date and time. Used with `TripUpdate.TripProperties.trip_id`, `TripUpdate.TripProperties.start_date`, and `TripUpdate.TripProperties.start_time` to copy an existing trip from static GTFS but start at a different service date and/or time. Duplicating a trip is allowed if the service related to the original trip in (CSV) GTFS (in `calendar.txt` or `calendar_dates.txt`) is operating within the next 30 days. The trip to be duplicated is identified via `TripUpdate.TripDescriptor.trip_id`.
This enumeration does not modify the existing trip referenced by `TripUpdate.TripDescriptor.trip_id` - if a producer wants to cancel the original trip, it must publish a separate `TripUpdate` with the value of CANCELED. Trips defined in GTFS `frequencies.txt` with `exact_times` that is empty or equal to `0` cannot be duplicated. The `VehiclePosition.TripDescriptor.trip_id` for the new trip must contain the matching value from `TripUpdate.TripProperties.trip_id` and `VehiclePosition.TripDescriptor.ScheduleRelationship` must also be set to `DUPLICATED`.
*Existing producers and consumers that were using the ADDED enumeration to represent duplicated trips must follow the [migration guide](../../realtime/examples//migration-duplicated) to transition to the DUPLICATED enumeration.* |
+| **NEW** | An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load. The complete journey of the new trip, including all stops and times, must be specified via `StopTimeUpdate`s.
*Existing producers and consumers that were using the ADDED enumeration to represent new trips unrelated to the static GTFS must follow the [migration guide](../../realtime/examples//migration-duplicated) to transition to the NEW enumeration.*
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
| **DELETED** | A trip that existed in the schedule but was removed that must not be shown to users.
DELETED should be used instead of CANCELED to indicate that a transit provider would like to entirely remove information about the corresponding trip from consuming applications, so the trip is not shown as cancelled to riders, e.g. a trip that is entirely being replaced by another trip. This designation becomes particularly important if several trips are cancelled and replaced with substitute service. If consumers were to show explicit information about the cancellations it would distract from the more important real-time predictions.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
## _message_ ModifiedTripSelector
@@ -592,7 +618,7 @@ Describes the physical path that a vehicle takes when the shape is not part of t
| _**Field Name**_ | _**Type**_ | _**Required**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|----------------|-------------------|-------------------|
| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Required | One | Identifier of the shape. Must be different than any `shape_id` defined in the (CSV) GTFS.
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
-| **encoded_polyline** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Required | One | Encoded polyline representation of the shape. This polyline must contain at least two points. For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
+| **encoded_polyline** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Required | One | Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used. For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
**Caution:** this field is still **experimental**, and subject to change. It may be formally adopted in the future. |
### _message_ Stop
@@ -695,8 +721,8 @@ List of selected trips with an associated shape.
| _**Field Name**_ | _**Type**_ | _**Required**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|----------------|-------------------|-------------------|
-| **trip_ids** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Many | One | A list of trip_id from the original (CSV) GTFS that are affected by the containing replacement. Need to contain at least one trip_id. |
-| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Required | One | The ID of the new shape for the modified trips in this SelectedTrips. May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt. |
+| **trip_ids** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Many | One | A list of trip_id from the original (CSV) GTFS that are affected by the containing replacement. Need to contain at least one trip_id. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip. |
+| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Required | One | The ID of the new shape for the modified trips in this SelectedTrips. May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt. If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`. |
### _message_ ReplacementStop
@@ -713,5 +739,5 @@ _If a modification affects the first stop of the trip, that stop also serves as
| _**Field Name**_ | _**Type**_ | _**Required**_ | _**Cardinality**_ | _**Description**_ |
|------------------|------------|----------------|-------------------|-------------------|
-| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Required | One | The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`. The stop MUST have `location_type=0` (routable stops). |
+| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Required | One | The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`. If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The stop MUST have `location_type=0` (routable stops). |
| **travel_time_to_stop** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Optional | One | The difference in seconds between the arrival time at this stop and the arrival time at the reference stop. The reference stop is the stop prior to `start_stop_selector`. If the modification begins at the first stop of the trip, then the first stop of the trip is the reference stop.
This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
If the value is not supplied, consumers MAY interpolate or infer the `travel_time_to_stop` based on other data. |
diff --git a/docs/es/documentation/realtime/change-history/revision-history.md b/docs/es/documentation/realtime/change-history/revision-history.md
index 204ff47d5..765a78f9b 100644
--- a/docs/es/documentation/realtime/change-history/revision-history.md
+++ b/docs/es/documentation/realtime/change-history/revision-history.md
@@ -2,6 +2,12 @@
## Historial de revisiones
+#### Mayo de 2025
+
+* Se deprecia schedule_relationship `ADDED` en favor de `NEW` y se añade `REPLACEMENT`. Consulte la [discusión](https://github.com/google/transit/pull/504).
+* Más aclaraciones sobre las modificaciones de viajes (Trip Modifications). Consulte la [discusión](https://github.com/google/transit/pull/542).
+
+
#### Diciembre de 2024
* Se agregó un nuevo campo de string que coincide con feed_info.feed_version de la fuente de GTFS Schedule en la que se basan los datos en tiempo real. Consulte la [discusión](https://github.com/google/transit/pull/434).
diff --git a/docs/es/documentation/realtime/examples/migration-duplicated.md b/docs/es/documentation/realtime/examples/migration-duplicated.md
index d383c3f30..be6e95ca6 100644
--- a/docs/es/documentation/realtime/examples/migration-duplicated.md
+++ b/docs/es/documentation/realtime/examples/migration-duplicated.md
@@ -1,25 +1,85 @@
-## Guía de migración: transición de viajes de AGREGADOS a DUPLICADOS (ADDED a DUPLICATED)
+## Guía de migración: transición de viajes de AGREGADOS a NUEVOS o DUPLICADOS (ADDED a NEW o DUPLICATED)
- El `DUPLICATED` de `trip.schedule_relationship` en GTFS Realtime representa un nuevo viaje que es igual a un viaje programado existente, excepto por la date y hora de inicio del servicio.
+El `trip.schedule_relationship` en tiempo real GTFS de `NEW` representa un nuevo viaje que se ejecuta según un horario independiente de cualquier viaje programado existente.
- Esta guía de migración define cómo los productores y consumidores existentes que utilizaban la enumeración "`ADDED`" para representar viajes duplicados deben realizar la transición a la enumeración "`DUPLICATED`". El objetivo es minimizar las perturbaciones para los productores y consumidores durante la transición.
+El `DUPLICATED` de `trip.schedule_relationship` en GTFS Realtime representa un nuevo viaje que es igual a un viaje programado existente, excepto por la date y hora de inicio del servicio.
- *Si usted es un productor o consumidor que **no** ha utilizado la enumeración `ADDED` para describir viajes duplicados, no es necesario realizar ninguna acción: puede producir/consumir viajes `DUPLICATED` sin producir/consumir ningúna entidad `ADDED`.*
+Esta guía de migración define cómo los productores y consumidores que usaban la enumeración `ADDED` deben realizar la transición a las enumeraciones `NEW` o `DUPLICATED`. El objetivo es minimizar las interrupciones para los productores y consumidores durante la transición.
+
+*Si usted es un productor o consumidor que **no** ha usado la enumeración `ADDED`, no se requiere ninguna acción: puede producir/consumir viajes `NEW` y/o `DUPLICATED` sin producir/consumir ninguna entidad `ADDED` .*
+
+Para obtener un historial completo de la enumeración `NEW`, consulte la [propuesta `NEW` y `REPLACEMENT` en GitHub](https://github.com/google/transit/pull/504).
- Para obtener un historial completo de la enumeración `DUPLICATED`, consulte la propuesta [`DUPLICATED` en GitHub](https://github.com/google/transit/pull/221).
+Para obtener un historial completo de la enumeración `DUPLICATED`, consulte la propuesta [`DUPLICATED` en GitHub](https://github.com/google/transit/pull/221).
+
+### A cuál migrar
+
+Tanto la enumeración `NEW` como la `DUPLICATED` se usan para especificar un viaje que no estaba originalmente programado para ejecutarse en la estática GTFS.
+
+Usar `NEW` si su viaje no puede describirse utilizando ningún viaje programado como plantilla. Por ejemplo, si el viaje hace escala en paradas diferentes a las de los viajes regulares de la ruta, o si el viaje adicional es de recogida solo al inicio de la ruta a pesar de que los viajes regulares permiten tanto la recogida como el descenso en todas las paradas.
+
+Use `DUPLICATED` si su viaje es una copia de un viaje programado, que puede ejecutarse al mismo tiempo o en horarios diferentes que el viaje programado original.
+
+### Uso de entidades ADDED y NEW en el mismo feed
+
+Si usted es un productor que ha estado usando la enumeración `ADDED` para especificar viajes que no están relacionados con el cronograma, para evitar interrupciones a los consumidores existentes, se recomienda que continúe produciendo entidades `ADDED` para estos viajes pero que también agregue entidades `NEW` para el mismo viaje.
+
+Sin embargo, para evitar que los consumidores agreguen accidentalmente el mismo viaje dos veces, las entidades que hacen referencia al mismo viaje **deben** estar vinculadas usando los mismos `trip_id`, `route_id` y `start_date`, el contenido de `stop_time_update` también debe ser el mismo.
+
+#### Productores
+
+~~~
+entidad {
+ id: "ei0"
+ trip_update {
+ trip: {
+ trip_id: "1"//<-- no se encontró un trip_id en el GTFS estático
+ route_id: "A"
+ schedule_relationship: AÑADIDO
+ start_date: "20200821"//<-- Nueva date de viaje
+ start_time: "11:30:00"//<-- Nueva hora de viaje
+ }
+ stop_time_update {
+...//La lista completa de los puntos de llamada del viaje
+ }
+ }
+}
+
+entidad {
+ id: "ei10"
+ trip_update {
+ trip: {
+ trip_id: "1"//<-- El mismo trip_id que el anterior
+ route_id: "A"//<-- El mismo route_id que el anterior
+ schedule_relationship: NEW
+ start_date: "20200821"//<-- La misma date que la anterior
+ start_time: "11:30:00"//<-- La misma hora que la anterior
+ }
+ stop_time_update {
+...//<-- El mismo contenido que el anterior
+ }
+ }
+}
+~~~
+
+Se sugiere que notifique a los consumidores existentes (por ejemplo, a través de una lista de correo para desarrolladores) que el uso de `ADDED` se considerará obsoleto en una fecha límite y los consumidores deberían comenzar a consumir los viajes "NUEVOS". También se debe mencionar la estrategia anterior que se utiliza para vincular las entidades de viaje `ADDED` y `NEW`, e incluir un enlace a esta guía de migración. Después de que pase la fecha límite, puede eliminar las entidades "`ADDED`" de su feed y publicar solo las entidades "`NEW`" para los viajes recientemente agregados.
+
+#### Consumidores
+
+Como se mencionó anteriormente, los productores harán la transición de enumeraciones `ADDED` a "`NEW`" publicando inicialmente dos entidades para cada nuevo viaje usando el mismo `trip_id` lo tanto, cuando un consumidor implementa soporte para viajes `NUEVOS`, es importante que los consumidores ignoren cualquier viaje `ADDED` que tenga el mismo `trip_id` que un viaje "`NEW`" `trip_id`
### Uso de entidades AÑADIDAS y DUPLICADAS en el mismo feed
#### Productores
- Si es un productor que ha estado utilizando la enumeración `ADDED` para viajes duplicados, para evitar interrupciones en Para los consumidores existentes, se recomienda que continúe produciendo entidades "`ADDED`" para estos viajes, pero también agregue entidades "`DUPLICATED`" para el mismo viaje.
-
- Sin embargo, para evitar que los consumidores agreguen accidentalmente el mismo viaje dos veces, las entidades que hacen referencia al mismo viaje **deben** estar vinculadas utilizando el mismo `trip_id`. Puede vincular las dos entidades en **una** de dos maneras:
+Si es un productor que ha estado utilizando la enumeración `ADDED` para viajes duplicados, para evitar interrupciones en Para los consumidores existentes, se recomienda que continúe produciendo entidades "`ADDED`" para estos viajes, pero también agregue entidades "`DUPLICATED`" para el mismo viaje.
+Sin embargo, para evitar que los consumidores agreguen accidentalmente el mismo viaje dos veces, las entidades que hacen referencia al mismo viaje **deben** estar vinculadas utilizando el mismo `trip_id`. Puede vincular las dos entidades en **una** de dos maneras:
+
1. `viaje.trip_id` de ambas entidades **debe** ser el mismo, O
2. `trip.trip_id` del viaje `ADDED` **debe** ser el mismo que el viaje `DUPLICATED` `trip_properties.trip_id`
-
- Aquí hay un ejemplo de la primera opción (1) para duplicar GTFS `d` 1`, con el `trip.trip_id` coincidente en las entidades `ADDED` y `DUPLICATED` :
+
+Aquí hay un ejemplo de la primera opción (1) para duplicar GTFS `trip_id=1`, con el `trip.trip_id` coincidente en las entidades `ADDED` y `DUPLICATED` :
~~~
entity {
@@ -94,13 +154,13 @@ entity {
~~~
- Se sugiere que notifique a los consumidores existentes (por ejemplo, a través de una lista de correo de desarrolladores) que el uso de "`ADDED`" para viajes duplicados está obsoleto antes de una fecha límite establecida y que los consumidores deberían empezar a consumir los viajes "`DUPLICATED`". También se debe mencionar la estrategia anterior que se utiliza para hacer coincidir las entidades de viaje "`ADDED`" y "`DUPLICATED`" y se debe incluir un enlace a esta guía de migración. Después de que pase la fecha límite, puede eliminar las entidades "`ADDED`" de su feed y publicar solo las entidades "`DUPLICATED`" para viajes duplicados.
+Se recomienda notificar a los consumidores actuales (por ejemplo, a través de una lista de correo para desarrolladores) que el uso de `ADDED` quedará obsoleto a partir de una fecha límite y que, en su lugar, los usuarios deberían empezar a consumir los viajes `DUPLICATED`. También se debe mencionar la estrategia anterior que se utiliza para vincular las entidades de viaje `ADDED` y `DUPLICATED`, e incluir un enlace a esta guía de migración. Después de que pase la fecha límite, puede eliminar las entidades `ADDED` de su feed y publicar solo las entidades `DUPLICATED` para los viajes duplicados.
#### Consumidores
- Como se mencionó anteriormente, los productores pasarán de enumeraciones "`ADDED`" a "`DUPLICATED`" publicando inicialmente dos entidades para cada viaje duplicado, utilizando una de las dos opciones anteriores para hacer coincidir las identificaciones entre las entidades.
+Como se mencionó anteriormente, los productores pasarán de enumeraciones "`ADDED`" a "`DUPLICATED`" publicando inicialmente dos entidades para cada viaje duplicado, utilizando una de las dos opciones anteriores para hacer coincidir las identificaciones entre las entidades.
- Por lo tanto, cuando un consumidor implementa soporte para viajes "`DUPLICATED`", es importante que los consumidores:
+Por lo tanto, cuando un consumidor implementa soporte para viajes "`DUPLICATED`", es importante que los consumidores:
1. Ignore cualquier viaje "`ADDED`" que tenga el mismo `trips.trip_id` como un viaje `DUPLICATED`. trip_id`
- 1. Ignore cualquier viaje `ADDED` que tenga el mismo `trips.trip_id` como un viaje `DUPLICATED` `trip_properties.trip_id`
\ No newline at end of file
+ 2. Ignore cualquier viaje `ADDED` que tenga el mismo `trips.trip_id` como un viaje `DUPLICATED` `trip_properties.trip_id`
\ No newline at end of file
diff --git a/docs/es/documentation/realtime/feed-entities/trip-updates.md b/docs/es/documentation/realtime/feed-entities/trip-updates.md
index 7545971f1..1788a06fe 100644
--- a/docs/es/documentation/realtime/feed-entities/trip-updates.md
+++ b/docs/es/documentation/realtime/feed-entities/trip-updates.md
@@ -13,7 +13,7 @@
## StopTimeUpdate
- Una actualización de viaje consta de una o más actualizaciones de los horarios de parada del vehículo, que se denominan [StopTimeUpdates](../../reference/#message-stoptimeupdate). Estos pueden suministrarse para horarios de parada pasados y futuros. Se le permite, pero no es obligatorio, pasar de los horarios de parada. Los productores no deben eliminar un `StopTimeUpdate` pasado si se refiere a una parada con una hora de llegada programada en el futuro para el viaje dado (es decir, el vehículo ha pasado la parada antes de lo previsto), ya que de lo contrario se concluirá que no hay actualización para esta parada.
+ Una actualización de viaje consta de una o más actualizaciones de los horarios de parada del vehículo, que se denominan [StopTimeUpdates](../../reference/#message-stoptimeupdate). Estos pueden suministrarse para horarios de parada pasados y futuros a menos que el viaje sea nuevo o de reemplazo y no se encuentre en la información estática de GTFS. Se le permite, pero no es obligatorio, pasar de los horarios de parada. Los productores no deben eliminar un `StopTimeUpdate` pasado si se refiere a una parada con una hora de llegada programada en el futuro para el viaje dado (es decir, el vehículo ha pasado la parada antes de lo previsto), ya que de lo contrario se concluirá que no hay actualización para esta parada.
Por ejemplo, si los siguientes datos aparecen en el feed GTFS-rt:
diff --git a/docs/es/documentation/realtime/gtfs-realtime.proto b/docs/es/documentation/realtime/gtfs-realtime.proto
index 34a8a20ab..e050fc19f 100644
--- a/docs/es/documentation/realtime/gtfs-realtime.proto
+++ b/docs/es/documentation/realtime/gtfs-realtime.proto
@@ -195,6 +195,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -277,6 +284,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -374,16 +407,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -798,14 +838,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -814,8 +850,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -824,7 +861,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -844,6 +884,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -869,8 +913,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1051,7 +1095,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1139,10 +1183,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1200,7 +1245,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
diff --git a/docs/es/documentation/realtime/proto.md b/docs/es/documentation/realtime/proto.md
index 6c9ebccd9..d64679663 100644
--- a/docs/es/documentation/realtime/proto.md
+++ b/docs/es/documentation/realtime/proto.md
@@ -199,6 +199,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -281,6 +288,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -378,16 +411,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -802,14 +842,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -818,8 +854,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -828,7 +865,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -848,6 +888,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -873,8 +917,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1055,7 +1099,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1143,10 +1187,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1204,7 +1249,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
diff --git a/docs/es/documentation/realtime/realtime-best-practices.md b/docs/es/documentation/realtime/realtime-best-practices.md
index e46fbc91b..7a178106f 100644
--- a/docs/es/documentation/realtime/realtime-best-practices.md
+++ b/docs/es/documentation/realtime/realtime-best-practices.md
@@ -48,7 +48,7 @@
Pautas generales para cancelaciones de viajes:
* Al cancelar viajes durante varios días, los productores deben proporcionar TripUpdates que hagan referencia a los `trip_ids` y `start_dates` dados como `CANCELED` así como una alerta con "`NO_SERVICE`" que hace referencia a los mismos "`trip_ids`" y "`TimeRange`" que se puede mostrar a los pasajeros explicando la cancelación (por ejemplo, desvío).
- * Si no se visitarán paradas en un viaje, el viaje debe ser `CANCELED` en lugar de tener todas las `stop_time_updates` marcadas como `SKIPPED`.
+ * Si no se visitarán paradas en un viaje, el viaje debe ser `CANCELED` en lugar de tener todos los `stop_time_updates` marcados como `SKIPPED`, a menos que el viaje fuera un viaje `NUEVO` o `DUPLICATED` y se haya cancelado posteriormente.
| Nombre del campo | Recomendación |
|---|---|
@@ -69,7 +69,13 @@
| Nombre del campo | Recomendación |
|---|---|
- | `schedule_relationship` | El comportamiento de los viajes "`ADDED`" no está especificado y no se recomienda el uso de esta enumeración. |
+ | `schedule_relationship` | El comportamiento de los viajes "`ADDED`" no está especificado y no se recomienda el uso de esta enumeración.
Si el viaje no está programado para ejecutarse originalmente, use "NUEVO" si no sigue el patrón de parada de un viaje existente, o "`DUPLICATED`" si es una copia de un viaje existente.
Si el viaje se ejecuta en un cronograma modificado o se detiene, pero se puede asociar a un viaje programado original en el GTFS estático, use `REPLACEMENT` y especifique la lista completa de horarios de parada para el viaje modificado. |
+
+### TripProperties
+
+| Nombre del campo | Recomendación |
+|---|---|
+| `trip_headsign` | Siempre se debe proporcionar para un viaje con `TripDescriptor.schedule_relationship` = `NEW`, y para un viaje con `TripDescriptor.schedule_relationship` = `REPLACEMENT` si el viaje se desvía. |
### VehicleDescriptor
@@ -97,6 +103,7 @@
| Nombre del campo | Recomendación |
|---|---|
| `delay` | Si solo se proporciona `delay` (y no `time`) en un `stop_time_update` `arrival` o `departure`, entonces el GTFS [`stop_times.txt`](../../schedule/reference/#stop_timestxt) debe contener `arrival_times` y/o `departure_times` para estas paradas correspondientes. Un valor de "`delay`" en el feed en tiempo real no tiene sentido a menos que tenga una hora de reloj para agregarlo en el archivo GTFS "`stop_times.txt`". |
+ | `scheduled_time` | Si el viaje es nuevo o de reemplazo, y se ejecutará según un cronograma (que puede ser modificado en caso de reemplazo), se debe proporcionar `scheduled_time` para todos los puntos de tiempo. Si un viaje duplicado tiene tiempos de ejecución o de permanencia diferentes a los del original, también se puede usar `scheduled_time` para especificarlos. |
### VehiclePosition
diff --git a/docs/es/documentation/realtime/reference.md b/docs/es/documentation/realtime/reference.md
index 137ae4547..9d8a52a9a 100644
--- a/docs/es/documentation/realtime/reference.md
+++ b/docs/es/documentation/realtime/reference.md
@@ -14,6 +14,7 @@
* **Obligatorio**: este campo debe ser proporcionado por un productor de feeds GTFS en tiempo real.
* **Requerido condicionalmente**: Este campo es obligatorio bajo ciertas condiciones, que se describen en el campo *Descripción*. Fuera de estas condiciones, el campo es opcional.
+ * **Prohibido condicionalmente**: Este campo está prohibido bajo ciertas condiciones, que se describen en el campo *Descripción*. Fuera de estas condiciones, el campo es opcional.
* **Opcional**: Este campo es opcional y no es necesario que lo implementen los productores. Sin embargo, si los datos están disponibles en los sistemas automáticos de localización de vehículos subyacentes (por ejemplo, VehiclePosition `timestamp`), se recomienda que los productores proporcionen estos campos opcionales cuando sea posible.
*Tenga en cuenta que los requisitos semánticos no se definieron en GTFS-realtime versión 1.0 y, por lo tanto, los feeds con `gtfs_realtime_version` de `1` pueden no cumplir con estos requisitos (consulte [la propuesta de requisitos semánticos](https://github.com/google/transit/pull/64) para más detalles).*
@@ -150,6 +151,7 @@
* Un viaje que se desarrolla según el cronograma.
* Un viaje que transcurre a lo largo de una ruta pero no tiene un horario fijo.
* Un viaje que ha sido agregado o eliminado con respecto al cronograma.
+ * Un viaje que reemplaza un viaje existente en GTFS estático.
* Un nuevo viaje que es una copia de un viaje existente en GTFS estático. Se ejecutará en la date y hora del servicio especificadas en TripProperties.
Las actualizaciones pueden ser para eventos futuros de llegada/salida previstos o para eventos pasados que ya ocurrieron. En la mayoría de los casos, la información sobre eventos pasados es un valor medido, por lo que se recomienda que su valor de incertidumbre sea 0\. Aunque podría haber casos en los que esto no se cumpla, se permite tener un valor de incertidumbre diferente de 0 para eventos pasados. Si la incertidumbre de una actualización no es 0, o la actualización es una predicción aproximada para un viaje que no se ha completado o la medición no es precisa o la actualización fue una predicción para el pasado que no se ha verificado después de que ocurrió el evento.
@@ -167,17 +169,18 @@
|------------------|------------|----------------|-------------------|-------------------|
| **trip** | [TripDescriptor](#message-tripdescriptor) | Obligatorio | Uno | El viaje al que se aplica este message. Puede haber como máximo una entidad TripUpdate para cada instancia de viaje real. Si no hay ninguno, significa que no hay información de predicción disponible. *No* significa que el viaje avanza según lo previsto. |
| **vehicle** | [VehicleDescriptor](#message-vehicledescriptor) | Opcional | Uno | Información adicional sobre el vehículo que realiza este viaje. |
- | **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) | Requerido condicionalmente | Muchos | Actualizaciones de StopTimes del viaje (tanto futuras, es decir, predicciones, como en algunos casos, pasadas, es decir, las que ya sucedieron). Las actualizaciones deben ordenarse por stop_sequence y aplicarse a todas las siguientes paradas del viaje hasta la siguiente stop_time_update especificada. Se debe proporcionar al menos un stop_time_update para el viaje a menos que trip.schedule_relationship esté CANCELADO, ELIMINADO o DUPLICADO. Si el viaje se cancela o elimina, no es necesario proporcionar stop_time_updates. Si se proporcionan stop_time_updates para un viaje cancelado o eliminado, trip.schedule_relationship tiene prioridad sobre cualquier stop_time_updates y su relación de programación asociada. Si el viaje está duplicado, se pueden proporcionar stop_time_updates para indicar información en tiempo real para el nuevo viaje. |
+ | **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) | Requerido condicionalmente | Muchos | Actualizaciones de StopTimes para el viaje (tanto futuras, es decir, predicciones, como en algunos casos, pasadas, es decir, las que ya ocurrieron). Las actualizaciones deben ordenarse por stop_sequence y se aplican a todas las paradas siguientes del viaje hasta la siguiente stop_time_update especificada.
Si trip.schedule_relationship está PROGRAMADO o NO PROGRAMADO, se debe proporcionar al menos una actualización de stop_time para el viaje.
Si trip.schedule_relationship es `NUEVO` o `REEMPLAZO`, se deben proporcionar stop_time_updates para todas las paradas en el viaje nuevo o de reemplazo, incluidas las paradas con horarios en el pasado, y no se utilizan los horarios de parada en el GTFS estático.
Si el viaje se cancela o se elimina, no es necesario proporcionar actualizaciones de tiempo de parada. Si se proporcionan actualizaciones de tiempo de parada para un viaje cancelado o eliminado, la relación de horarios del viaje (trip.schedule_relationship) prevalece sobre cualquier actualización de tiempo de parada y su relación de horarios asociada. Si el viaje se duplica, se pueden proporcionar actualizaciones de tiempo de parada para indicar información en tiempo real del nuevo viaje. |
| **timestamp** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | El momento más reciente en el que se midió el progreso del vehículo en tiempo real para estimar los tiempos de parada en el futuro. Cuando se proporcionan StopTimes en el pasado, los horarios de llegada/salida pueden ser anteriores a este valor. En hora POSIX (es decir, el número de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC). |
| **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | La desviación del horario actual para el viaje. El retraso solo debe especificarse cuando la predicción se proporciona en relación con algún cronograma existente en GTFS.
El retraso (en segundos) puede ser positivo (lo que significa que el vehículo llega tarde) o negativo (lo que significa que el vehículo está adelantado). Un retraso de 0 significa que el vehículo llega exactamente a tiempo.
La información de retraso en StopTimeUpdates tiene prioridad sobre la información de retraso a nivel de viaje, de modo que el retraso a nivel de viaje solo se propaga hasta la siguiente parada del viaje con un valor de retraso de StopTimeUpdate especificado.
Se recomienda encarecidamente a los proveedores de feeds que proporcionen un valor TripUpdate.timestamp que indique cuándo se actualizó por última vez el valor de retraso, para evaluar la actualización de los datos.
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.|
| **trip_properties** | [TripProperties](#message-tripproperties) | Opcional | Uno | Proporciona las propiedades actualizadas para el viaje.
**Precaución:**este message aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
### _message_ StopTimeEvent
- Información de tiempo para un único evento previsto (ya sea llegada o salida). El tiempo consiste en retraso y/o tiempo estimado e incertidumbre.
+ Información de tiempo para un único evento previsto (ya sea llegada o salida). El tiempo se compone del retraso o la hora estimada, y de la incertidumbre. También se puede agregar una hora programada para viajes `NUEVOS`, `REEMPLAZO` o `DUPLICATED`
* el retraso debe usarse cuando la predicción se da en relación con algún cronograma existente en GTFS.
- * Se debe dar tiempo independientemente de que exista un horario previsto o no. Si se especifican tanto la hora como el retraso, el tiempo tendrá prioridad (aunque normalmente, si se proporciona el tiempo para un viaje programado, debe ser igual al tiempo programado en GTFS + retraso).
+ * Se debe proporcionar la hora independientemente de si hay o no una programación prevista, y se debe proporcionar para viajes nuevos o de reemplazo. Si se especifican tanto la hora como el retraso, la hora tendrá prioridad (aunque normalmente, la hora, si se proporciona para un viaje programado, debe ser igual a la hora programada en GTFS + retraso).
+ * Se puede proporcionar la hora programada si el viaje es nuevo, de reemplazo o duplicado.
La incertidumbre se aplica tanto al tiempo como al retraso. La incertidumbre especifica aproximadamente el error esperado en el retraso real (pero tenga en cuenta que aún no definimos su significado estadístico preciso). Es posible que la incertidumbre sea 0, por ejemplo, para trenes que circulan bajo control de sincronización por computadora.
@@ -185,25 +188,28 @@
| _**Nombre de campo**_ | _**Tipo**_ | _**Obligatorio**_ | _**Cardenalidad**_ | _**Descripción**_ |
|------------------|------------|----------------|-------------------|-------------------|
- | **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | El retraso (en segundos) puede ser positivo (lo que significa que el vehículo llega tarde) o negativo (lo que significa que el vehículo está adelantado). Un retraso de 0 significa que el vehículo llega exactamente a tiempo. Se debe proporcionar el retraso o la hora dentro de un StopTimeEvent ; ambos campos no pueden estar vacíos. |
- | **time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | Evento como tiempo absoluto. En hora POSIX (es decir, número de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC). Se debe proporcionar el retraso o la hora dentro de un StopTimeEvent ; ambos campos no pueden estar vacíos. |
- | **uncertainty** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | Si se omite la incertidumbre, se interpreta como desconocida. Para especificar una predicción completamente segura, establezca su incertidumbre en 0. |
+ | **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Condicionalmente requerido | Uno | El retraso (en segundos) puede ser positivo (lo que significa que el vehículo va con retraso) o negativo (lo que significa que el vehículo va adelantado). Un retraso de 0 significa que el vehículo llega puntualmente.
**Prohibido** si StopTimeUpdate es NO_DATA.
**Obligatorio**; de lo contrario, si no se proporciona la hora. |
+ | **time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio condicionalmente | Uno | Evento estimado o real en tiempo absoluto. En tiempo POSIX (es decir, el número de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC).
**Prohibido** si StopTimeUpdate es NO_DATA.
**Obligatorio**de lo contrario, si no se especifica el retraso. |
+ | **scheduled_time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Condicionalmente prohibido | Uno | Hora programada. En tiempo POSIX (es decir, el número de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC).
**Opcional** si TripUpdate es `NUEVO`, `REEMPLAZO` o `DUPLICATED`;**prohibido**en caso contrario. |
+ | **uncertainty** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | Si se omite la incertidumbre, se interpreta como desconocida. Para especificar una predicción completamente segura, establezca su incertidumbre en 0.
**Prohibido** si StopTimeUpdate es NO_DATA. |
### _message_ StopTimeUpdate
Actualización en tiempo real de eventos de llegada y/o salida para una parada determinada de un viaje. Consulte también la discusión general sobre las actualizaciones de la hora de parada en la documentación [TripDescriptor](#message-tripdescriptor) y [entidades de actualizaciones de viaje](../../../documentation/realtime/feed-entities/trip-updates).
- Se pueden proporcionar actualizaciones para eventos pasados y futuros. Al productor se le permite, aunque no es obligatorio, descartar eventos pasados.
+ Se pueden proporcionar actualizaciones para eventos pasados y futuros. El productor puede, aunque no está obligado, omitir eventos pasados, a menos que `TripUpdate.schedule_relationship` sea `NEW` o `REPLACEMENT`. En tal caso, las paradas pasadas no deben omitirse, ya que definen el viaje en el que se encuentra el vehículo, hasta que este haya finalizado.
La actualización está vinculada a una parada específica ya sea a través de stop_sequence o stop_id, por lo que necesariamente se debe configurar uno de estos campos. Si se visita el mismo stop_id más de una vez en un viaje, entonces se debe proporcionar stop_sequence en todas las StopTimeUpdates para ese stop_id en ese viaje.
+
+ En viajes nuevos o de reemplazo, las actualizaciones se utilizan para especificar las paradas visitadas por el viaje sin hacer referencia a un viaje existente en el GTFS estático. En tales viajes, `stop_id`, `stop_sequence`, `departure` y `arrival` deben estar todos configurados.
**Campos**
| _**Nombre de campo**_ | _**Tipo**_ | _**Obligatorio**_ | _**Cardenalidad**_ | _**Descripción**_ |
|------------------|------------|----------------|-------------------|-------------------|
- | **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | Debe ser el mismo que en stop_times.txt en el feed GTFS correspondiente. Se debe proporcionar stop_sequence o stop_id dentro de StopTimeUpdate ; ambos campos no pueden estar vacíos.stop_sequence es necesario para viajes que visitan el mismo stop_id más de una vez (por ejemplo, un bucle) para eliminar la ambigüedad de para qué parada es la predicción. Si se completa "`StopTimeProperties.assigned_stop_id`", entonces se debe completar "`stop_sequence`". |
- | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | Debe ser el mismo que el del stops.txt del feed GTFS correspondiente. Se debe proporcionar stop_sequence o stop_id dentro de StopTimeUpdate ; ambos campos no pueden estar vacíos. Si se completa `StopTimeProperties.assigned_stop_id`, se prefiere omitir `stop_id` y usar solo `stop_sequence`. Si se completan `StopTimeProperties.assigned_stop_id` y `stop_id`, `stop_id` debe coincidir con `assigned_stop_id`. |
- | **arrival** | [StopTimeEvent](#message-stoptimeevent) | Requerido condicionalmente | Uno | Si Schedule_relationship está vacío o SCHEDULED, se debe proporcionar la llegada o la salida dentro de StopTimeUpdate ; ambos campos no pueden estar vacíos.la llegada y la salida pueden estar vacías cuando se SALTA la relación_programa. Si la relación_programa es NO_DATA, la llegada y la salida deben estar vacías. |
- | **departure** | [StopTimeEvent](#message-stoptimeevent) | Requerido condicionalmente | Uno | Si Schedule_relationship está vacío o SCHEDULED, se debe proporcionar la llegada o la salida dentro de StopTimeUpdate ; ambos campos no pueden estar vacíos.la llegada y la salida pueden estar vacías cuando se SALTA la relación_programa. Si la relación_programa es NO_DATA, la llegada y la salida deben estar vacías. |
+ | **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | Debe ser el mismo que en stop_times.txt en la fuente GTFS correspondiente. Se debe proporcionar stop_sequence o stop_id dentro de un StopTimeUpdate ; ambos campos no pueden estar vacíos. stop_sequence es necesario para viajes que visitan el mismo stop_id más de una vez (por ejemplo, un bucle) para desambiguar para qué parada es la predicción. Si se completa `StopTimeProperties.assigned_stop_id`, se debe completar `stop_sequence`. **Obligatorio** si `TripUpdate.schedule_relationship` es `NEW` o `REPLACEMENT`, y el valor debe aumentar a lo largo del viaje. |
+ | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | Debe ser el mismo que en stops.txt en la fuente GTFS correspondiente. Se debe proporcionar stop_sequence o stop_id dentro de un StopTimeUpdate ; ambos campos no pueden estar vacíos. Si se completa `StopTimeProperties.assigned_stop_id`, se prefiere omitir `stop_id` y usar solo `stop_sequence`. Si se completan `StopTimeProperties.assigned_stop_id` y `stop_id`, `stop_id` debe coincidir con `assigned_stop_id`. **Obligatorio** si `TripUpdate.schedule_relationship` es `NEW` o `REPLACEMENT`. |
+ | **arrival** | [StopTimeEvent](#message-stoptimeevent) | Requerido condicionalmente | Uno | Si schedule_relationship está vacío o PROGRAMADO, se debe proporcionar la llegada o la salida dentro de un StopTimeUpdate ; ambos campos no pueden estar vacíos. La llegada y la salida pueden estar vacías cuando schedule_relationship sea SKIPPED. **Obligatorio** si `TripUpdate.schedule_relationship` es `NEW` o `REPLACEMENT`. |
+ | **departure** | [StopTimeEvent](#message-stoptimeevent) | Requerido condicionalmente | Uno | Si schedule_relationship está vacío o PROGRAMADO, se debe proporcionar la llegada o la salida dentro de un StopTimeUpdate ; ambos campos no pueden estar vacíos. La llegada y la salida pueden estar vacías cuando se OMITA schedule_relationship. **Obligatorio** si `TripUpdate.schedule_relationship` es `NEW` o `REPLACEMENT`. |
| **departure_occupancy_status** | [OccupancyStatus](#enum-occupancystatus) | Opcional | Uno | El estado previsto de ocupación de pasajeros del vehículo inmediatamente después de la salida de la parada determinada. Si se proporciona, se debe proporcionar stop_sequence. Para proporcionar return_occupancy_status sin proporcionar predicciones de llegada o salida en tiempo real, complete este campo y establezca StopTimeUpdate.schedule_relationship = NO_DATA.
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship) | Opcional | Uno | La relación predeterminada es PROGRAMADA. |
| **stop_time_properties** | [StopTimeProperties](#message-stoptimeproperties) | Opcional | Uno | Actualizaciones en tiempo real para ciertas propiedades definidas en GTFS stop_times.txt
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
@@ -218,7 +224,7 @@
|-------------|---------------|
| **SCHEDULED** | El vehículo avanza según su programa estático de paradas, aunque no necesariamente según los horarios del programa. Este es el comportamiento predeterminado. Se debe proporcionar al menos uno de llegada y salida. Los viajes basados en frecuencia (GTFS frequencies.txt con exactitud_times = 0) no deben tener un valor SCHEDULED y en su lugar deben usar UNSCHEDULED. |
| **SKIPPED** | La parada se salta, es decir, el vehículo no se detendrá en esta parada. La llegada y salida son opcionales. Cuando se establece "`SKIPPED`" no se propaga a paradas posteriores en el mismo viaje (es decir, el vehículo se detendrá en paradas posteriores del viaje a menos que esas paradas también tengan un `stop_time_update` con `schedule_relationship: SKIPPED`). El retraso de una parada anterior en el viaje *se* propaga sobre la parada "`SKIPPED`". En otras palabras, si una `stop_time_update` con una predicción de `arrival` o `departure` no está configurada para una parada después de la parada `SKIPPED`, la predicción en sentido ascendente de la parada `SKIPPED` se propagará a la parada después de ` Parada `SKIPPED` y paradas posteriores en el viaje hasta que se proporcione una `stop_time_update` para una parada posterior. |
- | **NO_DATA** | No se facilitan datos de esta parada. Indica que no hay información de cronometraje en tiempo real disponible. Cuando se establece NO_DATA se propaga a través de paradas posteriores, por lo que esta es la forma recomendada de especificar de qué parada no tiene información de tiempo en tiempo real. Cuando se establece NO_DATA, no se debe proporcionar ni la llegada ni la salida. |
+ | **NO_DATA** | No se proporcionan datos en tiempo real para esta parada. Esto indica que no hay información de tiempo en tiempo real disponible. Cuando se establece NO_DATA, se propaga a través de las paradas posteriores, por lo que esta es la forma recomendada de especificar desde qué parada no tiene información de tiempo en tiempo real. Cuando NO_DATA está establecido, no se debe proporcionar la llegada ni la salida, a menos que `TripDescriptor.schedule_relationship` sea `NEW` o `REPLACEMENT`, en cuyo caso solo se debe proporcionar la hora programada, pero no las predicciones. Cuando `TripDescriptor.schedule_relationship` es `NEW` o `REPLACEMENT`, `arrival` y `departure` deben indicarse con sus horas programadas, ya que StopTimeUpdate define la lista de paradas del viaje. En este caso, indica que el horario no está relacionado con el GTFS estático, pero la predicción en tiempo real aún no está disponible. |
| **UNSCHEDULED** | El vehículo está realizando un viaje basado en frecuencia (GTFS frequencies.txt con exact_times = 0). Este valor no debe usarse para viajes que no están definidos en GTFS frequencies.txt, o viajes en GTFS frequencies.txt con exact_times = 1. Los Viajes que contienen `stop_time_updates` con `schedule_relationship: UNSCHEDULED` también deben configurar el TripDescriptor `schedule_relationship: UNSCHEDULED`
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.
### _message_ StopTimeProperties
@@ -232,6 +238,20 @@
| _**Nombre de campo**_ | _**Tipo**_ | _**Obligatorio**_ | _**Cardenalidad**_ | _**Descripción**_ |
|------------------|------------|----------------|-------------------|-------------------|
| **assigned_stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | Admite asignaciones de paradas en tiempo real. Se refiere a un `stop_id` definido en el `stops.txt` de GTFS.
El nuevo `assigned_stop_id` no debería resultar en una experiencia de viaje significativamente diferente para el usuario final que el `stop_id` definido en GTFS `stop_times.txt`. En otras palabras, el usuario final no debe ver este nuevo `stop_id` como un "cambio inusual" si la nueva parada se presentó dentro de una aplicación sin ningún contexto adicional. Por ejemplo, este campo está pensado para ser utilizado para asignaciones de plataformas mediante el uso de un `stop_id` que pertenece a la misma estación que la parada definida originalmente en GTFS `stop_times.txt`.
Para asignar una parada sin proporcionar predicciones de llegada o salida en tiempo real, complete este campo y establezca `StopTimeUpdate.schedule_relationship = NO_DATA`.
Si este campo está completo, se debe completar "`StopTimeUpdate.stop_sequence`" y no se debe completar "`StopTimeUpdate.stop_id`". Las asignaciones de paradas también deben reflejarse en otros campos GTFS en tiempo real (por ejemplo, `VehiclePosition.stop_id`).
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
+ | **stop_headsign** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | El letrero actualizado del vehículo en la parada.
**Precaución:** Este campo aún es**experimental**y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
+ | **drop_off_type** | [DropOffPickupType](#enum-dropoffpickuptype) | Opcional | Uno | La fecha de entrega actualizada del vehículo en la parada.
**Precaución:** Este campo aún es**experimental**y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
+ | **pickup_type** | [DropOffPickupType](#enum-dropoffpickuptype) | Opcional | Uno | La fecha de recogida actualizada del vehículo en la parada.
**Precaución:** este campo aún es**experimental**y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
+
+ ## _enum_ DropOffPickupType
+
+ **Valores**
+
+| _**Valor**_ | _**Comentario**_ |
+|----------------------------|--------------------------------------------------------|
+|**REGULAR**| Recogida/bajada programada regularmente. |
+|**NONE**| No hay recogida/bajada disponible. |
+|**PHONE_AGENCY**| Debe llamar a la agencia para organizar la recogida/bajada. |
+|**COORDINATE_WITH_DRIVER**| Debe coordinar con el conductor para organizar la recogida/bajada. |
### _message_ TripProperties
@@ -246,7 +266,9 @@
| **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | Define el identificador de un nuevo viaje que es un duplicado de un viaje existente definido en (CSV) GTFS trips.txt pero que comenzará en una date y/u hora de servicio diferente (definida usando `TripProperties.start_date` y `TripProperties.start_time`). Consulte la definición de `trips.trip_id` en (CSV) GTFS. Su valor debe ser diferente a los utilizados en el GTFS (CSV). Este campo es obligatorio si `schedule_relationship` es `DUPLICATED`; de lo contrario, este campo no debe completarse y los consumidores lo ignorarán.
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
| **start_date** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | date de servicio en la que se realizará el viaje duplicado. Debe proporcionarse en formato AAAAMMDD. Este campo es obligatorio si `schedule_relationship` es `DUPLICATED`; de lo contrario, este campo no debe completarse y los consumidores lo ignorarán.
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | Define la hora de inicio de salida del viaje cuando está duplicado. Consulte la definición de `stop_times.departure_time` en (CSV) GTFS. Los horarios de llegada y salida programados para el viaje duplicado se calculan en función del desfase entre el viaje original `departure_time` y este campo. Por ejemplo, si un viaje GTFS tiene una parada A con una `departure_time` de `10:00:00` y una parada B con una `departure_time` de `10:01:00`, y este campo se completa con el valor de `10:30:00`, la parada B en el viaje duplicado tendrá una `departure_time` programada de `10:31:00`. Los valores de "`delay`" de predicción en tiempo real se aplican a este tiempo de programación calculado para determinar el tiempo previsto. Por ejemplo, si se proporciona un "`delay`" de salida de "`30`" para la parada B, entonces la hora de salida prevista es "`10:31:30`". A los valores de "`time`" de predicción en tiempo real no se les aplica ningún desplazamiento e indican el tiempo previsto según lo previsto. Por ejemplo, si se proporciona una `time` de salida que representa las 10:31:30 para la parada B, entonces la hora de salida prevista es `10:31:30`. Este campo es obligatorio si `schedule_relationship` es `DUPLICATED`; de lo contrario, este El campo no debe completarse y los consumidores lo ignorarán.
**Precaución:** este campo sigue siendo **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
- | **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | Especifica la forma de la ruta de viaje del vehículo para este viaje cuando difiere de la original. Se refiere a una forma definida en GTFS (CSV) o una nueva entidad de forma en un feed en tiempo real. Consulte la definición de `trips.shape_id` en (CSV) GTFS.
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
+ | **trip_headsign** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | Especifica la señal de cabecera para este viaje cuando difiere del original.
**Precaución:** Este campo aún es **experimental** y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
+ | **trip_short_name** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | Especifica el nombre de este viaje cuando difiere del original.
**Precaución:** Este campo aún es **experimental** y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
+ | **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | Especifica el identificador de la forma (shape) de la ruta del vehículo cuando esta difiere de la especificada en (CSV) GTFS o para especificarla en tiempo real cuando no la proporciona (CSV) GTFS, como en el caso de un vehículo que toma rutas diferentes según la demanda de los pasajeros. Consulte la definición de `trips.shape_id` en (CSV) GTFS.
Si una forma no está definida en el archivo GTFS (CSV) ni en tiempo real, se considera desconocida. Este campo puede referirse a una forma definida en el archivo GTFS (CSV) en shapes.txt o a una `Shape` en el mismo feed en tiempo real (protobuf). El orden de las paradas (secuencias de paradas) para este viaje debe ser el mismo que en el archivo GTFS (CSV). Si se refiere a una entidad `Shape` en el mismo feed en tiempo real, el valor de este campo debe ser el del `shape_id` dentro de la entidad, y no el `id` de `FeedEntity`.
Las Paradas que forman parte del viaje original pero que ya no se realizarán, como cuando se produce un desvío, deben marcarse como `schedule_relationship=SKIPPED` o se pueden proporcionar más detalles a través de un message `TripModifications` .
**Precaución:** Este campo aún es **experimental** y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
### _message_ VehiclePosition
@@ -441,7 +463,7 @@
### _message_ TripDescriptor
- Un descriptor que identifica una instancia única de un viaje GTFS.
+ Un descriptor que identifica una sola instancia de un viaje GTFS, a menos que `schedule_relationship` sea `NEW`; en tal caso, especifica la nueva instancia del viaje que se añadirá.
Para especificar una única instancia de viaje, en muchos casos un `trip_id` por sí solo es suficiente. Sin embargo, los siguientes casos requieren información adicional para resolverse en una sola instancia de viaje:
@@ -457,32 +479,35 @@
TripDescriptor.route_id no se puede utilizar dentro de un EntitySelector de alerta para especificar una alerta para toda la ruta que afecte a todos los viajes de una ruta; utilice EntitySelector.route_id en su lugar.
+ Si `schedule_relationship` es `NEW`, `trip_id` debe establecerse en un valor que no figure en la fuente GTFS, y `route_id` debe establecerse en un valor que figure en `routes.txt` en la estática GTFS, para asociar el viaje a una ruta. Se debe establecer `start_date` y se puede establecer `direction_id` para el nuevo viaje.
+
**Campos**
| _**Nombre de campo**_ | _**Tipo**_ | _**Obligatorio**_ | _**Cardenalidad**_ | _**Descripción**_ |
|------------------|------------|----------------|-------------------|-------------------|
- | **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | El trip_id del feed GTFS al que hace referencia este selector. Para viajes no basados en frecuencia (viajes no definidos en GTFS frequencies.txt), este campo es suficiente para identificar de forma única el viaje. Para los viajes basados en frecuencia definidos en GTFS frequencies.txt, se requieren trip_id, start_time y start_date. Para viajes programados (viajes no definidos en frequencies.txt GTFS.txt), trip_id solo se puede omitir si el viaje se puede identificar de forma única mediante una combinación de route_id, direction_id, start_time y start_date, y se proporcionan todos esos campos. Cuando la relación_programación se DUPLICA dentro de TripUpdate, trip_id identifica el viaje del GTFS estático que se va a duplicar. Cuando la relación_programación está DUPLICADA dentro de VehiclePosition, trip_id identifica el nuevo viaje duplicado y debe contener el valor de TripUpdate correspondiente. TripProperties.trip_id. |
- | **route_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | El route_id del GTFS al que hace referencia este selector. Si se omite trip_id, route_id, direction_id, start_time y Schedule_relationship=SCHEDULED deben configurarse para identificar una instancia de viaje. TripDescriptor.route_id no debe usarse dentro de un Alert EntitySelector para especificar una alerta para toda la ruta que afecte a todos los viajes de una ruta; use EntitySelector.route_id en su lugar. |
+ | **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio condicional | Uno | El trip_id de la fuente GTFS a la que hace referencia este selector. Para viajes no basados en frecuencia (viajes no definidos en GTFS frequencies.txt), este campo es suficiente para identificar de forma única el viaje. Para viajes basados en frecuencia definidos en GTFS frequencies.txt, se requieren trip_id, start_time y start_date. Para viajes programados (viajes no definidos en GTFS frequencies.txt), trip_id solo se puede omitir si el viaje se puede identificar de forma única mediante una combinación de route_id, direction_id, start_time y start_date, y se proporcionan todos esos campos. Cuando schedule_relationship es NEW, se debe especificar con un valor único no definido en el GTFS estático. Cuando schedule_relationship es `REPLACEMENT`, trip_id identifica el viaje del GTFS estático que se va a reemplazar. Cuando schedule_relationship es `DUPLICATED` dentro de un TripUpdate, trip_id identifica el viaje del GTFS estático que se va a duplicar. Cuando schedule_relationship es `DUPLICATED` dentro de un VehiclePosition, trip_id identifica el nuevo viaje duplicado y debe contener el valor del TripUpdate correspondiente. TripProperties.trip_id. |
+ | **route_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio condicional | Uno | El route_id del GTFS al que hace referencia este selector. Si se omite trip_id, route_id, direction_id, start_time y schedule_relationship=SCHEDULED deben configurarse para identificar una instancia de viaje. TripDescriptor.route_id no debe usarse dentro de un EntitySelector de alertas para especificar una alerta para toda la ruta que afecte a todos los viajes de una ruta; utilice EntitySelector.route_id en su lugar. Si schedule_relationship es NEW, route_id debe especificarse para la ruta a la que pertenece el nuevo viaje. |
| **direction_id** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | El id_dirección del archivo trips.txt del feed GTFS, que indica la dirección de viaje de los viajes a los que hace referencia este selector. Si se omite trip_id, se debe proporcionar direction_id.
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.
|
| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | La hora de inicio inicialmente programada de esta instancia de viaje. Cuando trip_id corresponde a un viaje no basado en frecuencia, este campo debe omitirse o ser igual al valor en el feed GTFS. Cuando trip_id corresponde a un viaje basado en frecuencia definido en GTFS frequencies.txt, start_time es obligatorio y debe especificarse para las actualizaciones de viaje y las posiciones de los vehículos. Si el viaje corresponde a exactitud_times=1 registro GTFS, entonces start_time debe ser un múltiplo (incluido cero) de headway_secs posterior a frequencies.txt start_time para el período de tiempo correspondiente. Si el viaje corresponde a horas_exactas=0, entonces su hora_inicio puede ser arbitraria y se espera inicialmente que sea la primera salida del viaje. Una vez establecida, la hora de inicio de este viaje exacto_times=0 basado en frecuencia debe considerarse inmutable, incluso si cambia la primera hora de salida; ese cambio de hora puede reflejarse en un StopTimeUpdate. Si se omite trip_id, se debe proporcionar start_time. El formato y la semántica del campo son los mismos que los de GTFS/frequencies.txt/hora_inicio, por ejemplo, 11:15:35 o 25:15:35. |
| **start_date** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requerido condicionalmente | Uno | La date de inicio de esta instancia de viaje en formato AAAAMMDD. Para viajes programados (viajes no definidos en frequencies.txt GTFS.txt), se debe proporcionar este campo para eliminar la ambigüedad de los viajes que llegan tan tarde como para coincidir con un viaje programado para el día siguiente. Por ejemplo, para un tren que sale a las 8:00 y a las 20:00 todos los días y tiene un retraso de 12 horas, habría dos viajes distintos al mismo tiempo. Este campo se puede proporcionar, pero no es obligatorio, para horarios en los que tales colisiones son imposibles; por ejemplo, un servicio que se ejecuta según un horario horario donde un vehículo que llega una hora tarde ya no se considera relacionado con el horario. Este campo es obligatorio para viajes basados en frecuencia definidos en frequencies.txt GTFS.txt. Si se omite trip_id, se debe proporcionar start_date. |
| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship_1) | Opcional | Uno | La relación entre este viaje y el horario estático. Si TripDescriptor se proporciona en una alerta `EntitySelector`, los consumidores ignoran el campo `schedule_relationship` al identificar la instancia de viaje coincidente.
|**modified_trip**| [ModifiedTripSelector](#message-modifiedtripselector) | Opcional | Uno | Enlace a cualquier modificación realizada a este viaje (cambios de forma, eliminación o adición de paradas). Si se proporciona este campo, los campos `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` del `TripDescriptor` DEBE dejarse vacíos, para evitar confusiones por parte de los consumidores que no están buscando el valor `ModifiedTripSelector`.
-
### _enum_ ScheduleRelationship
- La relación entre este viaje y el horario estático. Si un viaje se realiza de acuerdo con un cronograma temporal, no reflejado en GTFS, entonces no debe marcarse como SCHEDULED, sino como ADDED.
+ La relación entre este viaje y la programación estática. Si se realiza un nuevo viaje según un cronograma temporal que no se refleja en GTFS, no se debe marcar como SCHEDULED, sino como NEW. Si se realiza según un cronograma modificado que no se refleja en GTFS, no se debe marcar como `SCHEDULED`, sino como `REPLACEMENT`.
**Valores**
| _**Valor**_ | _**Comentario**_ |
|-------------|---------------|
| **SCHEDULED** | Viaje que se ejecuta de acuerdo con su programación GTFS o que está lo suficientemente cerca del viaje programado como para asociarse con él. |
- | **ADDED** | Un viaje adicional que se agregó además de un horario en ejecución, por ejemplo, para reemplazar un vehículo averiado o para responder a una carga repentina de pasajeros. *NOTA: Actualmente, el comportamiento no está especificado para los feeds que utilizan este modo. Hay discusiones sobre GTFS GitHub [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221 ) [(3)](https://github.com/google/transit/pull/219) en torno a especificar o desaprobar completamente los viajes AGREGADOS y la documentación se actualizará cuando finalicen esas discusiones.* |
+ | **ADDED** | *NOTA: Este valor ha quedado obsoleto porque no se especificó su comportamiento. Use **DUPLICATED** para un viaje adicional que sea igual a un viaje programado, excepto en la fecha u hora de inicio, o **NEW** para un viaje adicional que no esté relacionado con un viaje existente.* |
| **UNSCHEDULED** | Un viaje que se está ejecutando sin ningún horario asociado: este valor se usa para identificar viajes definidos en frequencies.txt GTFS.txt con tiempos_exactos = 0. No debe usarse para describir viajes no definidos en frequencies.txt GTFS.txt, o viajes en GTFS. frequencies.txt con horas_exactas = 1. Los Viajes con `schedule_relationship: UNSCHEDULED` también deben configurar todas las StopTimeUpdates `schedule_relationship: UNSCHEDULED`|
| **CANCELED** | Un viaje que existía en el cronograma pero fue eliminado. |
+ | **REPLACEMENT** | Un viaje que reemplaza un viaje programado existente, por ejemplo, con un cambio de horario o una ruta desviada. El recorrido completo del viaje de reemplazo debe especificarse mediante `StopTimeUpdate`, y el horario original de la estática GTFS no se utiliza para la instancia reemplazada.
`REPLACEMENT` se puede usar si el viaje se realiza según un cronograma revisado, pero no se debe usar para comunicar desviaciones del cronograma en tiempo real (predicciones) si el vehículo está destinado a seguir el cronograma que figura en `stop_times.txt` del GTFS estático.
**Precaución:** Este campo aún es **experimental** y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
| **DUPLICATED** | Un nuevo viaje que es igual a un viaje programado existente excepto por la date y hora de inicio del servicio. Se utiliza con `TripUpdate.TripProperties.trip_id`, `TripUpdate.TripProperties.start_date` y `TripUpdate.TripProperties.start_time` para copiar un viaje existente desde GTFS estático pero comenzar en una date y/u hora de servicio diferente. Se permite duplicar un viaje si el servicio relacionado con el viaje original en (CSV) GTFS (en `calendar.txt` o `calendar_dates.txt`) está operando dentro de los próximos 30 días. El viaje a duplicar se identifica mediante `TripUpdate.TripDescriptor.trip_id`.
Esta enumeración no modifica el viaje existente al que hace referencia `TripUpdate.TripDescriptor.trip_id` ; si un productor desea cancelar el viaje original, debe publicar un `TripUpdate` separado con el valor CANCELADO. Los Viajes definidos en GTFS `frequencies.txt` con `exact_times` que esté vacío o igual a `0` no se pueden duplicar. El `VehiclePosition.TripDescriptor.trip_id` para el nuevo viaje debe contener el valor coincidente de `TripUpdate.TripProperties.trip_id` y `VehiclePosition.TripDescriptor.ScheduleRelationship` también debe estar configurado en `DUPLICATED`.
*Los productores y consumidores existentes que utilizaban la enumeración AGREGADA para representar viajes duplicados deben seguir la [guía de migración](../../realtime/examples/migration-duplicated) para realizar la transición a la enumeración DUPLICADA.* |
+ | **NEW** | Un viaje adicional no relacionado con los viajes existentes, por ejemplo, para responder a una carga repentina de pasajeros. El recorrido completo del nuevo viaje, incluyendo todas las paradas y horarios, debe especificarse mediante `StopTimeUpdate`.
*Los productores y consumidores existentes que usaban la enumeración `ADDED` para representar nuevos viajes no relacionados con el GTFS estático deben seguir la [guía de migración](../../realtime/examples/migration-duplicated) para realizar la transición a la NUEVA enumeración.*
**Precaución:**Este campo aún es**experimental**y está sujeto a cambios. Podría adoptarse formalmente en el futuro. |
| **DELETED** | Un viaje que existía en el cronograma pero que fue eliminado y que no debe mostrarse a los usuarios.
ELIMINADO debe usarse en lugar de CANCELADO para indicar que un proveedor de transporte desea eliminar por completo la información sobre el viaje correspondiente de las aplicaciones consumidoras, de modo que el viaje no se muestre como cancelado a los pasajeros, por ejemplo, un viaje que está siendo reemplazado por completo por otro viaje. Esta designación adquiere particular importancia si se cancelan varios viajes y se reemplazan con un servicio sustituto. Si los consumidores mostraran información explícita sobre las cancelaciones, esto distraería la atención de las predicciones más importantes en tiempo real.
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
## _message_ ModifiedTripSelector
@@ -593,7 +618,7 @@ Cuando un servicio se ve afectado por una modificación de viaje, se utiliza `Mo
| _**Nombre de campo**_ | _**Tipo**_ | _**Obligatorio**_ | _**Cardenalidad**_ | _**Descripción**_ |
|------------------|------------|----------------|-------------------|-------------------|
| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio | Uno | Identificador de la forma. Debe ser diferente de cualquier `shape_id` definido en GTFS (CSV).
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
- | **encoded_polyline** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio | Uno | Representación de polilínea codificada de la forma. Esta polilínea debe contener al menos dos puntos. Para obtener más información sobre las polilíneas codificadas, consulte https://developers.google.com/maps/documentation/utilities/polylinealgorithm
**Precaución:**este campo aún es **experimental** y está sujeto a cambios. Es posible que se adopte formalmente en el futuro. |
+ | **encoded_polyline** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio | Uno | Representación de polilínea codificada de la forma. Esta polilínea debe contener al menos dos puntos y representar la forma completa del recorrido donde se utiliza. Para obtener más información sobre polilíneas codificadas, consulte https://developers.google.com/maps/documentation/utilities/polylinealgorithm
**Precaución:** este campo aún es **experimental** y está sujeto a cambios. Puede adoptarse formalmente en el futuro. |
### _message_ Stop
@@ -696,8 +721,8 @@ Cuando un servicio se ve afectado por una modificación de viaje, se utiliza `Mo
| _**Nombre de campo**_ | _**Tipo**_ | _**Obligatorio**_ | _**Cardenalidad**_ | _**Descripción**_ |
|------------------|------------|----------------|-------------------|-------------------|
- | **trip_ids** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Muchos | Uno | Una lista de trip_id del GTFS original (CSV) que se ven afectados por el reemplazo contenedor. Debe contener al menos un trip_id. |
- | **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio | Uno | El ID de la nueva forma para los viajes modificados en este SelectedTrips. Puede hacer referencia a una nueva forma agregada mediante un message de forma GTFS-RT o a una forma existente definida en el archivo shapes.txt del feed GTFS-Static. |
+ | **trip_ids** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Muchos | Uno | Una lista de trip_id del GTFS original (CSV) que se ven afectados por el reemplazo que los contiene. Debe contener al menos un trip_id. No debe existir ya un `TripUpdate` con `schedule_relationship=REPLACEMENT` para el viaje. |
+ | **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio | Uno | El ID de la nueva forma para los viajes modificados en este SelectedTrips. Puede referirse a una nueva forma añadida mediante un message `Shape` en la misma fuente GTFS-RT, o a una forma existente definida en el shapes.txt de la fuente GTFS-Static. Si se refiere a una entidad `Shape` en la fuente en tiempo real, el valor de este campo debe ser el del `shape_id` dentro de la entidad, y no el `id` de `FeedEntity`. |
### _message_ ReplacementStop
@@ -714,6 +739,6 @@ Cuando un servicio se ve afectado por una modificación de viaje, se utiliza `Mo
| _**Nombre de campo**_ | _**Tipo**_ | _**Obligatorio**_ | _**Cardenalidad**_ | _**Descripción**_ |
|------------------|------------|----------------|-------------------|-------------------|
- | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio | Uno | El ID de parada de reemplazo que ahora visitará el viaje. Puede hacer referencia a una nueva parada agregada mediante un message`Stop` GTFS-RT, o a una parada existente definida en el `stops.txt` del feed GTFS (CSV). La parada DEBE tener `location_type=0` (paradas enrutables). |
+ | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatorio | Uno | El ID de la parada de reemplazo que visitará el viaje. Puede referirse a una nueva parada añadida mediante un message `Stop` de GTFS-RT en el mismo feed GTFS-RT, o a una parada existente definida en el `stops.txt` del feed GTFS (CSV). Si se refiere a una entidad `Shape` en el feed en tiempo real, el valor de este campo debe ser el del `stop_id` dentro de la entidad, y no el `id` de `FeedEntity`. La parada DEBE tener `location_type=0` (paradas enrutables). |
| **travel_time_to_stop** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Opcional | Uno | La diferencia en segundos entre la hora de llegada a esta parada y la hora de llegada a la parada de referencia. La parada de referencia es la parada anterior a `start_stop_selector`. Si la modificación comienza en la primera parada del viaje, entonces la primera parada del viaje es la parada de referencia.
Este valor DEBE aumentar monótonamente y solo puede ser un número negativo si la primera parada del viaje original es la parada de referencia.
Si no se proporciona el valor, los consumidores PUEDE interpolar o inferir el `travel_time_to_stop` en función de otros datos. |
\ No newline at end of file
diff --git a/docs/fr/documentation/realtime/change-history/revision-history.md b/docs/fr/documentation/realtime/change-history/revision-history.md
index dda268ca6..4afb2c433 100644
--- a/docs/fr/documentation/realtime/change-history/revision-history.md
+++ b/docs/fr/documentation/realtime/change-history/revision-history.md
@@ -2,6 +2,11 @@
### Historique des révisions
+#### Mai 2025
+
+* Déprécie schedule_relationship `ADDED` au profit de `NEW` et ajoute `REPLACEMENT`. Voir [discussion](https://github.com/google/transit/pull/504).
+* Clarifications supplémentaires concernant les modifications de trajet. Voir [discussion](https://github.com/google/transit/pull/542).
+
#### Décembre 2024
* Ajout d’un nouveau champ de string qui correspond à feed_info.feed_version du flux de GTFS Schedule sur lequel les données en temps réel sont basées. Voir [discussion](https://github.com/google/transit/pull/434).
diff --git a/docs/fr/documentation/realtime/examples/migration-duplicated.md b/docs/fr/documentation/realtime/examples/migration-duplicated.md
index c3027d304..50c578f0d 100644
--- a/docs/fr/documentation/realtime/examples/migration-duplicated.md
+++ b/docs/fr/documentation/realtime/examples/migration-duplicated.md
@@ -1,23 +1,87 @@
-## Guide de migration- Transition des voyages AJOUTÉS aux voyages DUPLICATED
+## Guide de migration- Transition des trajets ADDED vers NEW ou DUPLICATED
- La `trip.schedule_relationship` en temps réel GTFS de `DUPLICATED` représente un nouveau voyage qui est identique à un voyage programmé existant, à l’exception de la date et de l’heure de début du service.
-
- Ce guide de migration définit comment les producteurs et consommateurs existants qui utilisaient l’énumération `ADDED` pour représenter les voyages dupliqués doivent passer à l’énumération `DUPLICATED`. L’objectif est de minimiser les perturbations pour les producteurs et les consommateurs pendant la transition.
+ La relation GTFS en temps réel `trip.schedule_relationship` de `NEW` représente un nouveau trajet qui s’exécute selon un horaire indépendant de tout trajet planifié existant.
+
+ La `trip.schedule_relationship` en temps réel GTFS de `DUPLICATED` représente un nouveau trajet qui est identique à un trajet programmé existant, à l’exception de la date et de l’heure de début du service.
- *Si vous êtes un producteur ou un application réutilisatrice qui n’a **pas** utilisé l’énumération `ADDED` pour décrire les voyages en double, aucune action n’est requise- vous pouvez produire/consommer des voyages `DUPLICATED` sans produire/consommer aucun `ADDED`. Entités ADDED` .*
+ Ce guide de migration définit comment les producteurs et les consommateurs existants qui utilisaient l’énumération `ADDED` doivent passer à l’énumération `NEW` ou `DUPLICATED`. L’objectif est de minimiser les perturbations pour les producteurs et les consommateurs pendant la transition.
+
+ *Si vous êtes un producteur ou un consommateur qui n’a **pas** utilisé l’énumération `ADDED`, aucune action n’est requise- vous pouvez produire/consommer des trajets `NEW` et/ou `DUPLICATED` sans produire/consommer d’entités `ADDED` .*
+
+ Pour un historique complet de l’énumération `NEW`, consultez la [proposition `NEW` et `REPLACEMENT` sur GitHub](https://github.com/google/transit/pull/504).
Pour un historique complet de l’énumération `DUPLICATED`, voir la [proposition `DUPLICATED` sur GitHub](https://github.com/google/transit/pull/221).
+
+### Vers lequel migrer
+
+Les énumérations `NEW` et `DUPLICATED` sont toutes deux utilisées pour spécifier un trajet qui n’était pas initialement prévu pour s’exécuter dans le GTFS statique.
+
+Utilisez `NEW` si votre trajet ne peut pas être décrit en utilisant comme modèle des trajets planifiés. Par exemple, si le trajet s’arrête à des arrêts différents de ceux des trajets réguliers de l’itinéraire, ou si le trajet supplémentaire permet uniquement la prise en charge au début de l’itinéraire malgré le fait que les trajets réguliers permettent à la fois la prise en charge et la dépose à tous les arrêts.
+
+Utilisez `DUPLICATED` si votre trajet est une copie d’un trajet planifié, qui peut avoir lieu au même moment ou à des heures différentes du trajet initialement prévu.
+
+### Utilisation des entités ADDED et NEW dans le même flux
+
+Si vous êtes un producteur qui a utilisé l’énumération `ADDED` pour spécifier des trajets qui ne sont pas liés à l’horaire, pour éviter de perturber les consommateurs existants, il est recommandé de continuer à produire des entités `ADDED` pour ces trajets, mais également d’ajouter des entités `NEW` pour le même trajet.
+
+Cependant, pour empêcher les consommateurs d’ajouter accidentellement le même trajet deux fois, les entités référençant le même trajet**doivent**être liées en utilisant les mêmes `trip_id`, `route_id` et `start_date`.
+De plus, le contenu de `stop_time_update` doit également être le même.
+
+#### Producteurs
+
+~~~
+entity {
+ id: "ei0"
+ trip_update {
+ trip: {
+ trip_id: "1"//<-- un trip_id non trouvé dans le GTFS statique
+ route_id: "A"
+ schedule_relationship: ADDED
+ start_date: "20200821"//<-- Nouvelle date de trajet
+ start_time: "11:30:00"//<-- Nouvelle heure de trajet
+ }
+ stop_time_update {
+...//La liste complète des points d’appel du trajet
+ }
+ }
+}
+
+entity {
+ id: "ei10"
+ trip_update {
+ trip: {
+ trip_id: "1"//<-- Le même trip_id que ci-dessus
+ route_id: "A"//<-- Le même route_id que ci-dessus
+ schedule_relationship: NEW
+ start_date: "20200821"//<-- La même date que ci-dessus
+ start_time: "11:30:00"//<-- La même heure que ci-dessus
+ }
+ stop_time_update {
+...//<-- Le même contenu que ci-dessus
+ }
+ }
+}
+~~~
+
+Il est suggéré d’informer les consommateurs existants (par exemple, via une liste de diffusion pour développeurs) que l’utilisation de `ADDED` est en cours. Les clients devraient désormais utiliser les trajets « NEW ». La stratégie ci-dessus, utilisée pour associer les entités de voyage « `ADDED` » et « NEW », doit également être mentionnée, et un lien vers ce guide de migration doit être inclus. Une fois le délai écoulé, vous pouvez supprimer les entités « ADDED » de votre flux et publier uniquement les entités « NEW » pour les voyages nouvellement ajoutés.
+
+#### Consommateurs
+
+Comme mentionné ci-dessus, les producteurs passeront des énumérations « `ADDED` » à « NEW » en publiant initialement deux entités pour chaque nouveau trajet utilisant le même « `trip_id` ».
+
+Par conséquent, lorsqu’un consommateur implémente la prise en charge des trajets « NEW », il est important que les consommateurs ignorent tous les trajets « `ADDED` » qui ont le même « `trip_id` » `trip_id` trajet « NEW ».
+
### Utilisation des entités ADDED et DUPLICATED dans le même flux
#### Producteurs
- Si vous êtes un producteur qui a utilisé l’énumération `ADDED` pour des voyages en double, pour éviter toute interruption de consommateurs existants, il est recommandé de continuer à produire des entités `ADDED` pour ces voyages mais également d’ajouter des entités `DUPLICATED` pour le même voyage.
+ Si vous êtes un producteur qui a utilisé l’énumération `ADDED` pour des trajets en double, pour éviter toute interruption de consommateurs existants, il est recommandé de continuer à produire des entités `ADDED` pour ces trajets mais également d’ajouter des entités `DUPLICATED` pour le même trajet.
- Cependant, pour éviter que les consommateurs ajoutent accidentellement deux fois le même voyage, les entités faisant référence au même voyage **doivent** être liées en utilisant le même `trip_id`. Vous pouvez relier les deux entités de **l’une** des deux manières suivantes :
+ Cependant, pour éviter que les consommateurs ajoutent accidentellement deux fois le même trajet, les entités faisant référence au même trajet **doivent** être liées en utilisant le même `trip_id`. Vous pouvez relier les deux entités de **l’une** des deux manières suivantes :
1. `trip.trip_id` des deux entités **doit** être le même, OU
- 2. `trip.trip_id` du voyage `ADDED` **doit** être le même que le voyage `DUPLICATED` `trip_properties.trip_id`
+ 2. `trip.trip_id` du trajet `ADDED` **doit** être le même que le trajet `DUPLICATED` `trip_properties.trip_id`
Voici un exemple de la première option (1) pour dupliquer GTFS `trip_id 1`, avec le `trip.trip_id` correspondant dans les entités `ADDED` et `DUPLICATED`:
@@ -56,7 +120,7 @@ entity {
}
~~~
- Voici un exemple de la deuxième option (2) pour dupliquer GTFS `trip_id 1`, avec le `trip.trip_id` du voyage `ADDED` correspondant au voyage `DUPLICATED` `trip_properties.trip_id` :
+ Voici un exemple de la deuxième option (2) pour dupliquer GTFS `trip_id 1`, avec le `trip.trip_id` du trajet `ADDED` correspondant au trajet `DUPLICATED` `trip_properties.trip_id` :
~~~
entity {
@@ -93,13 +157,13 @@ entity {
}
~~~
- Il est suggéré d’informer les consommateurs existants (par exemple, via une liste de diffusion de développeur·euse ) que l’utilisation de `ADDED` pour les voyages en double est obsolète avant une date limite définie et que les consommateurs devraient plutôt commencer à consommer les voyages `DUPLICATED`. La stratégie ci-dessus utilisée pour faire correspondre les entités de voyage `ADDED` et `DUPLICATED` doit également être mentionnée et un lien vers ce guide de migration doit être inclus. Une fois la date limite passée, vous pouvez supprimer les entités `ADDED` de votre flux et publier uniquement les entités `DUPLICATED` pour les voyages en double.
+ Il est suggéré d’informer les consommateurs existants (par exemple, via une liste de diffusion pour développeurs) que l’utilisation de `ADDED` est obsolète avant une date limite définie et que les consommateurs doivent commencer à consommer les trajets `DUPLICATED` à la place. La stratégie ci-dessus utilisée pour faire correspondre les entités de trajet « `ADDED` » et « `DUPLICATED` » doit également être mentionnée et un lien vers ce guide de migration doit être inclus. Une fois le délai passé, vous pouvez supprimer les entités « `ADDED` » de votre flux et publier uniquement les entités « `DUPLICATED` » pour les trajets dupliqués.
#### Consommateurs
- Comme mentionné ci-dessus, les producteurs passeront des énumérations `ADDED` à `DUPLICATED` en publiant initialement deux entités pour chaque voyage dupliqué, en utilisant l’une des deux options ci-dessus pour faire correspondre les identifiants entre les entités.
+ Comme mentionné ci-dessus, les producteurs passeront des énumérations `ADDED` à `DUPLICATED` en publiant initialement deux entités pour chaque trajet dupliqué, en utilisant l’une des deux options ci-dessus pour faire correspondre les identifiants entre les entités.
Par conséquent, lorsqu’un application réutilisatrice implémente la prise en charge des trajets `DUPLICATED`, il est important que les consommateurs :
-1. Ignorent tous les trajets `ADDED` qui ont le même `trip.trip_id` en tant que voyage `DUPLICATED` `trip.trip_id`
-1. Ignorez tous les voyages `ADDED` qui ont le même `trip.trip_id` en tant que voyage `DUPLICATED` `trip_properties.trip_id`
\ No newline at end of file
+1. Ignorent tous les trajets `ADDED` qui ont le même `trip.trip_id` en tant que trajet `DUPLICATED` `trip.trip_id`
+1. Ignorez tous les trajets `ADDED` qui ont le même `trip.trip_id` en tant que trajet `DUPLICATED` `trip_properties.trip_id`
\ No newline at end of file
diff --git a/docs/fr/documentation/realtime/feed-entities/trip-updates.md b/docs/fr/documentation/realtime/feed-entities/trip-updates.md
index c6f5de340..7cb4d8caa 100644
--- a/docs/fr/documentation/realtime/feed-entities/trip-updates.md
+++ b/docs/fr/documentation/realtime/feed-entities/trip-updates.md
@@ -13,7 +13,8 @@
## StopTimeUpdate
- Une mise à jour de trajet consiste en une ou plusieurs mises à jour des horaires d’arrêts du véhicule, appelées [StopTimeUpdates](../../reference/#message-stoptimeupdate). Ceux-ci peuvent être fournis pour les horaires d’arrêts passés et futurs. Vous êtes autorisé, mais pas obligé, à dépasser les horaires d’arrêts. Les producteurs ne doivent pas supprimer un `StopTimeUpdate` passé s’il fait référence à un arrêt avec une heure d’arrivée prévue dans le futur pour le trajet donné (c’est-à-dire que le véhicule a dépassé l’arrêt plus tôt que prévu), sinon il sera conclu qu’il n’y a pas d’arrêt.mise à jour pour cet arrêt.
+ Une mise à jour de trajet consiste en une ou plusieurs mises à jour des horaires d’arrêts du véhicule, appelées [StopTimeUpdates](../../reference/#message-stoptimeupdate). Ceux-ci peuvent être fournis pour les horaires d’arrêts passés et futurs. Vous êtes autorisé, mais pas obligé, d'enlever des horaires d’arrêts précédents, sauf si le trajet est un nouveau trajet ou un trajet de remplacement non trouvé dans la GTFS statique. Les producteurs ne doivent pas supprimer une `StopTimeUpdate` passée si elle fait référence à un arrêt avec une heure d’arrivée prévue dans le futur pour le trajet donné (c’est-à-dire que le véhicule a dépassé l’arrêt plus tôt que prévu), sinon il sera conclu qu’il n’y a pas de mise à jour pour cet arrêt.
+
Par exemple, si les données suivantes apparaissent dans le flux GTFS-rt :
diff --git a/docs/fr/documentation/realtime/gtfs-realtime.proto b/docs/fr/documentation/realtime/gtfs-realtime.proto
index 34a8a20ab..e050fc19f 100644
--- a/docs/fr/documentation/realtime/gtfs-realtime.proto
+++ b/docs/fr/documentation/realtime/gtfs-realtime.proto
@@ -195,6 +195,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -277,6 +284,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -374,16 +407,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -798,14 +838,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -814,8 +850,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -824,7 +861,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -844,6 +884,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -869,8 +913,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1051,7 +1095,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1139,10 +1183,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1200,7 +1245,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
diff --git a/docs/fr/documentation/realtime/proto.md b/docs/fr/documentation/realtime/proto.md
index 6f3c37829..d88b4cf68 100644
--- a/docs/fr/documentation/realtime/proto.md
+++ b/docs/fr/documentation/realtime/proto.md
@@ -199,6 +199,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -281,6 +288,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -378,16 +411,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -802,14 +842,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -818,8 +854,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -828,7 +865,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -848,6 +888,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -873,8 +917,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1055,7 +1099,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1143,10 +1187,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1204,7 +1249,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1216,4 +1262,3 @@ message ReplacementStop {
extensions 9000 to 9999;
}
```
-
diff --git a/docs/fr/documentation/realtime/realtime-best-practices.md b/docs/fr/documentation/realtime/realtime-best-practices.md
index 2d4e0e928..1b2557dd6 100644
--- a/docs/fr/documentation/realtime/realtime-best-practices.md
+++ b/docs/fr/documentation/realtime/realtime-best-practices.md
@@ -48,7 +48,7 @@
Directives générales pour les annulations de voyage :
* Lors de l’annulation de voyages sur plusieurs jours, les producteurs doivent fournir des TripUpdates faisant référence aux `trip_ids` et aux `start_dates` donnés comme `CANCELED`. ainsi qu’une alerte avec `NO_SERVICE` faisant référence aux mêmes `trip_ids` et `TimeRange` qui peuvent être montrées aux passagers expliquant l’annulation (par exemple, un détour).
- * Si aucun arrêt d’un voyage n’est visité, le voyage doit être `CANCELED` au lieu d’avoir toutes les `stop_time_updates` marquées comme `SKIPPED`.
+ * Si aucun arrêt d’un trajet n’est visité, le trajet doit être `CANCELED` au lieu d’avoir tous les `stop_time_updates` marqués comme `SKIPPED`, à moins que le trajet ne soit un trajet `NOUVEAU` ou `DUPLICATED` et qu’il ait été annulé par la suite.
| Nom du champ | Recommandation |
|---|---|
@@ -69,7 +69,13 @@
| Nom du champ | Recommandation |
|---|---|
- | `schedule_relationship` | Le comportement des déplacements `ADDED` n’est pas spécifié et l’utilisation de cette énumération n’est pas recommandée. |
+ | `schedule_relationship` | Le comportement des voyages « `ADDED` » n’est pas spécifié et l’utilisation de cette énumération n’est pas recommandée.
Si le trajet n’est pas prévu pour s’exécuter à l’origine, utilisez « NOUVEAU » s’il ne suit pas le modèle d’arrêt d’un trajet existant, ou « `DUPLICATED` » s’il s’agit d’une copie d’un trajet existant.
Si le trajet s’effectue selon un horaire ou des arrêts modifiés, mais peut être associé à un trajet planifié d’origine dans le GTFS statique, utilisez `REPLACEMENT` et spécifiez la liste complète des horaires d’arrêts pour le trajet modifié. |
+
+### TripProperties
+
+| Nom du champ | Recommandation |
+|---|---|
+| `trip_headsign` | Doit toujours être fourni pour un trajet avec `TripDescriptor.schedule_relationship` = `NEW`, et fourni pour un trajet avec `TripDescriptor.schedule_relationship` = `REPLACEMENT` si le trajet est dévié. |
### VehicleDescriptor
@@ -97,6 +103,7 @@
| Nom du champ | Recommandation |
|---|---|
| `delay` | Si seul `delay` est fourni dans une `stop_time_update` `arrival` ou `departure` (et non `time`), alors le GTFS [`stop_times.txt`](../../schedule/reference/#stop_timestxt ) doit contenir `arrival_times` et/ou `departure_times` pour ces arrêts correspondants. Une valeur `delay` dans le flux en temps réel n’a de sens que si vous disposez d’une heure à laquelle l’ajouter dans le fichier GTFS `stop_times.txt`. |
+ | `scheduled_time` | Si le trajet est un trajet nouveau ou de remplacement, et qu’il est exécuté selon un planning (qui peut être un planning modifié en cas de trajet de remplacement), « scheduled_time » doit être fourni pour tous les points temporels. Si les trajets dupliqués ont des temps d’exécution ou de séjour différents de l’original, « scheduled_time » peut également être utilisé pour les spécifier. |
### VehiclePosition
diff --git a/docs/fr/documentation/realtime/reference.md b/docs/fr/documentation/realtime/reference.md
index a3385a7f4..0ba57e451 100644
--- a/docs/fr/documentation/realtime/reference.md
+++ b/docs/fr/documentation/realtime/reference.md
@@ -14,6 +14,7 @@
* **Requis** : Ce champ doit être fourni par un producteur de flux GTFS Realtime.
* **Requis sous condition** : Ce champ est obligatoire sous certaines conditions, qui sont décrites dans le champ *Description*. En dehors de ces conditions, le champ est facultatif.
+ * **Interdit sous condition**: ce champ est interdit sous certaines conditions, qui sont décrites dans le champ *Description*. En dehors de ces conditions, le champ est facultatif.
* **Optionnel** : Ce champ est facultatif et n’a pas besoin d’être implémenté par les producteurs. Cependant, si les données sont disponibles dans les systèmes de localisation automatique des véhicules sous-jacents (par exemple, VehiclePosition `timestamp`), il est recommandé aux producteurs de fournir ces champs facultatifs lorsque cela est possible.
*Notez que les exigences sémantiques n’ont pas été définies dans la version 1.0 de GTFS-realtime, et par conséquent les flux avec `gtfs_realtime_version` de `1` peuvent ne pas répondre à ces exigences (voir [la proposition d’exigences sémantiques](https://github.com/google/transit/pull/64) pour plus de détails).*
@@ -149,6 +150,7 @@
* Un voyage qui se déroule selon le planning.
* Un voyage qui s’effectue le long d’un itinéraire mais n’a pas d’horaire fixe.
* Un trajet qui a été ajouté ou supprimé par rapport à l’horaire.
+ * Un trajet qui remplace un trajet existant dans GTFS statique.
* Un nouveau voyage qui est une copie d’un voyage existant en GTFS statique. Il s’exécutera à la date et à l’heure de service spécifiées dans TripProperties.
Les mises à jour peuvent concerner des événements d’arrivée/départ futurs et prévus, ou des événements passés déjà survenus. Dans la plupart des cas, les informations sur les événements passés sont une valeur mesurée, il est donc recommandé que sa valeur d’incertitude soit 0\. Bien qu’il puisse y avoir des cas où cela ne soit pas le cas, il est donc permis d’avoir une valeur d’incertitude différente de 0 pour les événements passés. Si l’incertitude d’une mise à jour n’est pas 0, soit la mise à jour est une prédiction approximative pour un voyage qui n’est pas terminé, soit la mesure n’est pas précise, soit la mise à jour est une prédiction pour le passé qui n’a pas été vérifiée après que l’événement s’est produit.
@@ -166,17 +168,18 @@
|--------|------------|----------------|----------------------------------|-------------------|
| **trip** | [TripDescriptor](#message-tripdescriptor) | Requis | Un | Le voyage auquel ce message s’applique. Il peut y avoir au plus une entité TripUpdate pour chaque instance de voyage réelle. S’il n’y en a pas, cela signifie qu’aucune information de prédiction n’est disponible. Cela ne signifie *pas* que le voyage se déroule comme prévu. |
| **vehicle** | [VehicleDescriptor](#message-vehicledescriptor) | Optionnel | Un | Informations complémentaires sur le véhicule qui assure ce trajet. |
- | **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) | Requis sous condition | Plusieurs | Mises à jour des StopTimes pour le voyage (à la fois futures, c’est-à-dire les prévisions, et dans certains cas, passées, c’est-à-dire celles qui se sont déjà produites). Les mises à jour doivent être triées par stop_sequence et s’appliquer à tous les arrêts suivants du trajet jusqu’au prochain stop_time_update spécifié. Au moins un stop_time_update doit être fourni pour le voyage, sauf si trip.schedule_relationship est CANCELED, DELETED ou DUPLICATED. Si le voyage est annulé ou supprimé, aucun stop_time_updates ne doit être fourni. Si des stop_time_updates sont fournis pour un voyage annulé ou supprimé, alors trip.schedule_relationship a priorité sur tous les stop_time_updates et leur planning_relationship associé. Si le trajet est dupliqué, stop_time_updates peut être fourni pour indiquer des informations en temps réel pour le nouveau trajet. |
+ | **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) | Requis sous condition | Plusieurs | Mises à jour des StopTimes pour le voyage (à la fois futures, c’est-à-dire les prévisions, et dans certains cas, passées, c’est-à-dire celles qui se sont déjà produites). Les mises à jour doivent être triées par stop_sequence et s’appliquer à tous les arrêts suivants du trajet jusqu’au prochain stop_time_update spécifié.
Si trip.schedule_relationship est SCHEDULED ou UNSCHEDULED, au moins un stop_time_update doit être fourni pour le voyage.
Si trip.schedule_relationship est « NEW » ou « REPLACEMENT », stop_time_updates doit être fourni pour tous les arrêts du nouveau voyage ou du voyage de remplacement, y compris les arrêts avec des heures dans le passé, et les horaires d’arrêts dans le GTFS statique ne sont pas utilisées.
Si le voyage est annulé ou supprimé, aucune information stop_time_updates n’est requise. Si des informations stop_time_updates sont fournies pour un voyage annulé ou supprimé, la relation trip.schedule_relationship prévaut sur les informations stop_time_updates et leur relation schedule_relationship associée. Si le voyage est dupliqué, des informations stop_time_updates peuvent être fournies pour fournir des informations en temps réel pour le nouveau voyage. |
| **timestamp** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Moment le plus récent auquel la progression en temps réel du véhicule a été mesurée pour estimer les StopTimes dans le futur. Lorsque des StopTimes passés sont fournis, les heures d’arrivée/départ peuvent être antérieures à cette valeur. En temps POSIX (c’est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). |
| **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | L’écart d’horaire actuel pour le voyage. Le délai ne doit être spécifié que lorsque la prédiction est donnée par rapport à un calendrier existant dans GTFS.
Le retard (en secondes) peut être positif (ce qui signifie que le véhicule est en retard) ou négatif (ce qui signifie que le véhicule est en avance sur l’horaire prévu). Un retard de 0 signifie que le véhicule est exactement à l’heure.
Les informations de retard dans StopTimeUpdates ont priorité sur les informations de retard au niveau du déclenchement, de sorte que le retard au niveau du déclenchement se propage uniquement jusqu’au prochain arrêt du trajet avec une valeur de délai StopTimeUpdate spécifiée.
Les fournisseurs de flux sont fortement encouragés à fournir une valeur TripUpdate.timestamp indiquant la dernière fois que la valeur du délai a été mise à jour, afin d’évaluer la fraîcheur des données.
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.|
| **trip_properties** | [TripProperties](#message-tripproperties) | Optionnel | Un | Fournit les propriétés mises à jour pour le voyage.
**Attention :**ce message est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
### _message_ StopTimeEvent
- Informations de synchronisation pour un seul événement prédit (arrivée ou départ). Le timing comprend le retard et/ou le temps estimé et l’incertitude.
+ Informations de synchronisation pour un événement prédit unique (arrivée ou départ). La synchronisation comprend le retard, le temps estimé et l’incertitude. Une heure planifiée peut également être ajoutée pour les trajets « NOUVEAU », « REMPLACEMENT » ou « `DUPLICATED`
- * le délai doit être utilisé lorsque la prédiction est donnée par rapport à un calendrier existant dans GTFS.
- * L’heure doit être indiquée, qu’il y ait un horaire prévu ou non. Si l’heure et le retard sont spécifiés, l’heure aura la priorité (bien que normalement, l’heure, si elle est donnée pour un trajet programmé, doit être égale à l’heure programmée en GTFS + délai).
+ * Le délai doit être utilisé lorsque la prédiction est donnée par rapport à un calendrier existant dans GTFS.
+ * L’heure doit être indiquée, qu’il y ait un horaire prévu ou non, et doit être indiquée pour les trajets nouveaux ou de remplacement. Si l’heure et le retard sont tous deux spécifiés, l’heure aura la priorité (bien que normalement, l’heure, si elle est donnée pour un trajet planifié, doive être égale à l’heure planifiée dans GTFS + retard).
+ * L’heure planifiée peut être indiquée si le trajet est un trajet nouveau, de remplacement ou dupliqué.
L’incertitude s’applique également au temps et au retard. L’incertitude spécifie approximativement l’erreur attendue dans le délai réel (mais notez que nous ne définissons pas encore sa signification statistique précise). Il est possible que l’incertitude soit de 0, par exemple pour les trains circulant sous contrôle de synchronisation informatique.
@@ -184,25 +187,28 @@
| _**Nom du champ**_ | _**Tapez**_ | _**Requis**_ | _**Cardinalité**_ | _**Description**_ |
|--------|------------|----------------|----------------------------------|-------------------|
- | **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Le retard (en secondes) peut être positif (ce qui signifie que le véhicule est en retard) ou négatif (ce qui signifie que le véhicule est en avance sur l’horaire prévu). Un retard de 0 signifie que le véhicule est exactement à l’heure. Soit le délai, soit l’heure doivent être fournis dans un StopTimeEvent- les deux champs ne peuvent pas être vides. |
- | **time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Événement en temps absolu. En temps POSIX (c’est-à-dire nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). Soit le délai, soit l’heure doivent être fournis dans un StopTimeEvent- les deux champs ne peuvent pas être vides. |
- | **uncertainty** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Si l’incertitude est omise, elle est interprétée comme inconnue. Pour spécifier une prédiction totalement certaine, définissez son incertitude sur 0. |
+ | **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionnellement requis | Un | Le délai (en secondes) peut être positif (ce qui signifie que le véhicule est en retard) ou négatif (ce qui signifie que le véhicule est en avance sur l’horaire). Un délai de 0 signifie que le véhicule est exactement à l’heure.
**Interdit** si StopTimeUpdate.schedule_relationship est NO_DATA.
**Requis** sinon si l’heure n’est pas indiquée. |
+ | **time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Obligatoire sous condition | Un | Événement estimé ou réel sous forme d’heure absolue. En heure POSIX (c’est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC).
**Interdit**si StopTimeUpdate.schedule_relationship est NO_DATA.
**Requis** sinon si le délai n’est pas donné. |
+ | **scheduled_time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | Interdit conditionnel | Un | Heure planifiée. En heure POSIX (c’est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC).
**Optionnel** si TripUpdate.schedule_relationship est `NEW`, `REPLACEMENT` ou `DUPLICATED`, **interdit** sinon. |
+ | **uncertainty** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Si l’incertitude est omise, elle est interprétée comme inconnue. Pour spécifier une prédiction complètement certaine, définissez son incertitude à 0.
**Interdit** si StopTimeUpdate.schedule_relationship est NO_DATA. |
### _message_ StopTimeUpdate
Mise à jour en temps réel des événements d’arrivée et/ou de départ pour un arrêt donné d’un voyage. Veuillez également vous référer à la discussion générale sur les mises à jour des horaires d'arrêt dans la documentation [TripDescriptor](#message-tripdescriptor) et [trip mises à jour entités](../../../documentation/realtime/feed-entities/trip-updates).
- Des mises à jour peuvent être fournies pour les événements passés et futurs. Le producteur est autorisé, bien que cela ne soit pas obligatoire, à abandonner les événements passés.
+ Les mises à jour peuvent être fournies pour les événements passés et futurs. Le producteur est autorisé, mais non obligé, à supprimer les événements passés, sauf si `TripUpdate.schedule_relationship` est `NEW` ou `REPLACEMENT`. Dans ce cas, les arrêts passés ne doivent pas être supprimés car ils définissent le trajet effectué par le véhicule, jusqu’à ce que le trajet soit terminé.
La mise à jour est liée à un arrêt spécifique soit via stop_sequence soit stop_id, donc l’un de ces champs doit obligatoirement être renseigné. Si le même stop_id est visité plus d’une fois au cours d’un trajet, alors stop_sequence doit être fourni dans toutes les StopTimeUpdates pour ce stop_id lors de ce trajet.
+
+ Dans les trajets nouveaux ou de remplacement, les mises à jour sont utilisées pour spécifier les arrêts visités par le trajet sans faire référence à un trajet existant dans le GTFS Static. Français Dans de tels voyages, `stop_id`, `stop_sequence`, `departure` et `arrival` doivent tous être définis.
**Champs**
| _**Nom du champ**_ | _**Tapez**_ | _**Requis**_ | _**Cardinalité**_ | _**Description**_ |
|--------|------------|----------------|----------------------------------|-------------------|
- | **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Doit être le même que dans stop_times.txt dans le flux GTFS correspondant.stop_sequence ou stop_id doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides.stop_sequence est requis pour les trajets qui visitent le même stop_id plus d’une fois (par exemple, une boucle) pour lever l’ambiguïté à quel arrêt la prédiction est destinée. Si `StopTimeProperties.assigned_stop_id` est renseigné, alors `stop_sequence` doit être renseigné. |
- | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Doit être le même que dans le fichier stops.txt du flux GTFS correspondant.stop_sequence ou stop_id doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. Si `StopTimeProperties.assigned_stop_id` est renseigné, il est préférable d’omettre `stop_id` et d’utiliser uniquement `stop_sequence`. Si `StopTimeProperties.assigned_stop_id` et `stop_id` sont renseignés, `stop_id` doit correspondre à `assigned_stop_id`. |
- | **arrival** | [StopTimeEvent](#message-stoptimeevent) | Requis sous condition | Un | Si Schedule_relationship est vide ou SCHEDULED, l’arrivée ou le départ doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. L’arrivée et le départ peuvent tous deux être vides lorsque Schedule_relationship est SKIPPED. Si Schedule_relationship est NO_DATA, l’arrivée et le départ doivent être vides. |
- | **departure** | [StopTimeEvent](#message-stoptimeevent) | Requis sous condition | Un | Si Schedule_relationship est vide ou SCHEDULED, l’arrivée ou le départ doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. L’arrivée et le départ peuvent tous deux être vides lorsque Schedule_relationship est SKIPPED. Si Schedule_relationship est NO_DATA, l’arrivée et le départ doivent être vides. |
+ | **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionnellement requis | Un | Doit être le même que dans stop_times.txt dans le flux GTFS correspondant. Soit stop_sequence soit stop_id doit être fourni dans un StopTimeUpdate- les deux champs ne peuvent pas être vides.stop_sequence est requis pour les voyages qui visitent le même stop_id plusieurs fois (par exemple, une boucle) pour lever l’ambiguïté à l’arrêt auquel la prédiction est destinée. Si `StopTimeProperties.assigned_stop_id` est renseigné, alors `stop_sequence` doit être renseigné. **Requis** si `TripUpdate.schedule_relationship` est `NEW` ou `REPLACEMENT`, et la valeur doit augmenter tout au long du trajet. |
+ | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionnellement requis | Un | Doit être le même que dans stops.txt dans le flux GTFS correspondant. Soit stop_sequence soit stop_id doit être fourni dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. Si `StopTimeProperties.assigned_stop_id` est renseigné, il est préférable d’omettre `stop_id` et d’utiliser uniquement `stop_sequence`. Si `StopTimeProperties.assigned_stop_id` et `stop_id` sont renseignés, `stop_id` doit correspondre à `assigned_stop_id`. **Requis** si `TripUpdate.schedule_relationship` est `NEW` ou `REPLACEMENT`. |
+ | **arrival** | [StopTimeEvent](#message-stoptimeevent) | Conditionnellement requis | Un | Si schedule_relationship est vide ou PRÉVU, l’arrivée ou le départ doit être fourni dans un StopTimeUpdate- les deux champs ne peuvent pas être vides.arrival et departure peuvent tous deux être vides lorsque schedule_relationship est SKIPPED. **Requis** si `TripUpdate.schedule_relationship` est `NEW` ou `REPLACEMENT`. |
+ | **departure** | [StopTimeEvent](#message-stoptimeevent) | Conditionnellement requis | Un | Si schedule_relationship est vide ou SCHEDULED, l’arrivée ou le départ doit être fourni dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. L’arrivée et le départ peuvent tous deux être vides lorsque schedule_relationship est SKIPPED. **Requis** si `TripUpdate.schedule_relationship` est `NEW` ou `REPLACEMEN`T`.
| **departure_occupancy_status** | [OccupancyStatus](#enum-occupancystatus) | Optionnel | Un | L’état prévu d’occupation des passagers pour le véhicule immédiatement après le départ de l’arrêt donné. S’il est fourni, stop_sequence doit être fourni. Pour fournir exit_occupancy_status sans fournir de prévisions d’arrivée ou de départ en temps réel, remplissez ce champ et définissez StopTimeUpdate.schedule_relationship = NO_DATA.
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship) | Optionnel | Un | La relation par défaut est PLANIFIÉE. |
| **stop_time_properties** | [StopTimeProperties](#message-stoptimeproperties) | Optionnel | Un | Mises à jour en temps réel pour certaines propriétés définies dans GTFS stop_times.txt
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
@@ -217,7 +223,7 @@
|-------------|--------------------|
| **SCHEDULED** | Le véhicule avance conformément à son horaire d’arrêts statique, mais pas nécessairement selon les horaires de l’horaire. Ceci est le comportement par défaut. Au moins un d’arrivée et de départ doit être fourni. Les trajets basés sur la fréquence (GTFS frequencies.txt avec exact_times = 0) ne doivent pas avoir de valeur SCHEDULED et doivent plutôt utiliser UNSCHEDULED. |
| **SKIPPED** | L’arrêt est sauté, c’est-à-dire que le véhicule ne s’arrêtera pas à cet arrêt. L’arrivée et le départ sont facultatifs. Lorsqu’il est défini, `SKIPPED` n’est pas propagé aux arrêts suivants du même trajet (c’est-à-dire que le véhicule s’arrêtera aux arrêts suivants du trajet à moins que ces arrêts n’aient également un `stop_time_update` avec `schedule_relationship: SKIPPED`). Le retard par rapport à un arrêt précédent du trajet *se* se propage à l’arrêt « `SKIPPED` ». En d’autres termes, si un `stop_time_update` avec une prédiction `arrival` ou `departure` n’est pas défini pour un arrêt après l’arrêt `SKIPPED`, la prédiction en amont de l’arrêt `SKIPPED` sera propagée à l’arrêt après le ` Arrêt `SKIPPED` et arrêts suivants dans le trajet jusqu’à ce qu’un `stop_time_update` pour un arrêt ultérieur soit fourni. |
- | **NO_DATA** | Aucune donnée n’est fournie pour cet arrêt. Cela indique qu’aucune information de synchronisation en temps réel n’est disponible. Lorsque NO_DATA est défini, il se propage aux arrêts suivants. C’est donc la méthode recommandée pour spécifier à partir de quel arrêt vous n’avez pas d’informations de synchronisation en temps réel. Lorsque NO_DATA est défini, ni l’arrivée ni le départ ne doivent être fournis. |
+ | **NO_DATA** | Aucune donnée en temps réel n’est fournie pour cet arrêt. Cela indique qu’il n’y a pas d’informations de chronométrage en temps réel disponibles. Lorsque NO_DATA est défini, il est propagé aux arrêts suivants, c’est donc la méthode recommandée pour spécifier à partir de quel arrêt vous n’avez pas d’informations de chronométrage en temps réel. Lorsque NO_DATA est défini, l’arrivée ou le départ ne doivent pas être fournis, sauf si `TripDescriptor.schedule_relationship` est `NEW` ou `REPLACEMENT`, auquel cas seule l’heure prévue, mais pas les prévisions, doit être fournie. Lorsque `TripDescriptor.schedule_relationship` est `NEW` ou `REPLACEMENT`, `arrival` et `departure` doivent toujours être fournis avec les heures prévues, car StopTimeUpdate définit la liste d’arrêts du voyage. Dans ce cas, cela indique que l’horaire n’est pas lié au GTFS statique, mais que la prédiction en temps réel n’est pas encore disponible. |
| **UNSCHEDULED** | Le véhicule effectue un trajet basé sur la fréquence (GTFS frequencies.txt avec exact_times = 0). Cette valeur ne doit pas être utilisée pour les trajets qui ne sont pas définis dans GTFS frequencies.txt, ou pour les trajets dans GTFS frequencies.txt avec exact_times = 1. Les trajets contenant `stop_time_updates` avec `schedule_relationship: UNSCHEDULED` doivent également définir le TripDescriptor `schedule_relationship: UNSCHEDULED`
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
### _message_ StopTimeProperties
@@ -231,6 +237,20 @@
| _**Nom du champ**_ | _**Tapez**_ | _**Requis**_ | _**Cardinalité**_ | _**Description**_ |
|--------|------------|----------------|----------------------------------|-------------------|
| **assigned_stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Prend en charge les affectations d’arrêt en temps réel. Fait référence à un `stop_id` défini dans le GTFS `stops.txt`.
Le nouveau « `assigned_stop_id` » ne devrait pas entraîner une expérience de voyage significativement différente pour l'utilisateur final que le « `stop_id` » défini dans GTFS « `stop_times.txt` ». En d’autres termes, l'utilisateur final ne doit pas considérer ce nouveau « `stop_id` » comme un « changement inhabituel » si le nouvel arrêt a été présenté dans une application sans aucun contexte supplémentaire. Par exemple, ce champ est destiné à être utilisé pour les affectations de quai en utilisant un `stop_id` qui appartient à la même station que l’arrêt initialement défini dans GTFS `stop_times.txt`.
Pour attribuer un arrêt sans fournir de prévisions d’arrivée ou de départ en temps réel, remplissez ce champ et définissez `StopTimeUpdate.schedule_relationship = NO_DATA`.
Si ce champ est renseigné, `StopTimeUpdate.stop_sequence` doit être renseigné et `StopTimeUpdate.stop_id` ne doit pas être renseigné. Les affectations d’arrêt doivent également être reflétées dans d’autres champs GTFS Realtime (par exemple, `VehiclePosition.stop_id`).
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
+ | **stop_headsign** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Le panneau de signalisation mis à jour du véhicule à l’arrêt.
**Attention :**ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté à l’avenir. |
+| **drop_off_type** | [DropOffPickupType](#enum-dropoffpickuptype) | Optionnel | Un | Le lieu de dépôt mis à jour du véhicule à l’arrêt.
**Attention :**ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté ultérieurement. |
+| **pickup_type** | [DropOffPickupType](#enum-dropoffpickuptype) | Optionnel | Un | Le point de prise en charge mis à jour du véhicule à l’arrêt.
**Attention :**ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté à l’avenir. |
+
+## _enum_ DropOffPickupType
+
+**Valeurs**
+
+| _**Valeur**_ | _**Commentaire**_ |
+|----------------------------|--------------------------------------------------------|
+|**RÉGULIER**| Prise en charge/dépôt programmé régulièrement. |
+|**AUCUN**| Aucun point de prise en charge/dépose disponible. |
+|**PHONE_AGENCY**| Doit téléphoner à l’agence pour organiser la prise en charge/dépose. |
+|**COORDINATE_WITH_DRIVER**| Doit vous coordonner avec le chauffeur pour organiser la prise en charge/dépose. |
### _message_ TripProperties
@@ -245,7 +265,9 @@
| **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Définit l’identifiant d’un nouveau voyage qui est un doublon d’un voyage existant défini dans (CSV) GTFS trips.txt mais qui commencera à une date et/ou une heure de service différente (définie à l’aide de `TripProperties.start_date` et `TripProperties.start_time`). Voir la définition de `trips.trip_id` dans (CSV) GTFS. Sa valeur doit être différente de celles utilisées dans le (CSV) GTFS. Ce champ est obligatoire si `schedule_relationship` est `DUPLICATED`, sinon ce champ ne doit pas être renseigné et sera ignoré par les consommateurs.
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
| **start_date** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | date de prestation à laquelle le trajet dupliqué sera effectué. Doit être fourni au format AAAAMMJJ. Ce champ est obligatoire si `schedule_relationship` est `DUPLICATED`, sinon ce champ ne doit pas être renseigné et sera ignoré par les consommateurs.
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Définit l’heure de début de départ du trajet lorsqu’il est dupliqué. Voir la définition de `stop_times.departure_time` dans (CSV) GTFS. Les heures d’arrivée et de départ prévues pour le voyage dupliqué sont calculées en fonction du décalage entre le voyage d’origine `departure_time` et ce champ. Par exemple, si un trajet GTFS a l’arrêt A avec une `departure_time` de `10:00:00` et l’arrêt B avec une `departure_time` de `10:01:00`, et que ce champ est renseigné avec la valeur `10:30:00`, l’arrêt B du trajet dupliqué aura une `departure_time` programmée de `10:31:00`. Des valeurs de `delay` de prédiction en temps réel sont appliquées à cette heure programmée calculée pour déterminer l’heure prédite. Par exemple, si un `delay` de départ de `30` est prévu pour l’arrêt B, alors l’heure de départ prévue est `10:31:30`. Les valeurs `time` de prédiction en temps réel ne sont soumises à aucun décalage et indiquent l’heure prédite telle que fournie. Par exemple, si une `time` de départ représentant 10:31:30 est fournie pour l’arrêt B, alors l’heure de départ prévue est `10:31:30`. Ce champ est obligatoire si `schedule_relationship` est `DUPLICATED`, sinon ce champ est obligatoire. Le champ ne doit pas être renseigné et sera ignoré par les consommateurs.
**Attention :** son domaine est encore **expérimental** et sujet à changement. Il pourrait être formellement adopté à l’avenir. |
- | **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Spécifie la forme du trajet du véhicule pour ce trajet lorsqu’il diffère de l’original. Fait référence à une forme définie dans le GTFS (CSV) ou à une nouvelle entité de forme dans un flux en temps réel. Voir la définition de `trips.shape_id` dans (CSV) GTFS.
**Attention :** ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
+ | **trip_headsign** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Spécifie le panneau de signalisation pour ce trajet lorsqu’il diffère de l’original.
**Attention :**ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté à l’avenir. |
+ | **trip_short_name** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Spécifie le nom de ce voyage lorsqu’il diffère de l’original.
**Attention :**ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté ultérieurement. |
+ | **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | Spécifie l’identifiant de la forme du trajet du véhicule lorsque la forme du trajet diffère de celle spécifiée dans (CSV) GTFS ou pour la spécifier en temps réel lorsqu’elle n’est pas fournie par (CSV) GTFS, comme un véhicule qui emprunte des chemins différents en fonction de la demande des passagers. Voir la définition de `trips.shape_id` dans (CSV) GTFS.
Si une forme n’est définie ni dans le fichier GTFS (CSV) ni en temps réel, elle est considérée comme inconnue. Ce champ peut faire référence à une forme définie dans le fichier GTFS (CSV) dans shapes.txt ou à une `Shape` du même flux temps réel (protobuf). L’ordre des arrêts (séquences d’arrêts) pour ce trajet doit rester identique à celui du fichier GTFS (CSV). S’il fait référence à une entité « `Shape` » du même flux temps réel, la valeur de ce champ doit être celle de l’ `shape_id` » de l’entité, et non celle de `id` « `FeedEntity` ».
Les Arrêts qui font partie du voyage d’origine mais qui ne seront plus effectués, par exemple lorsqu’un détour se produit, doivent être marqués comme schedule_relationship=SKIPPED ou plus de détails peuvent être fournis via un message « `TripModifications` » .
**Attention :**ce champ est encore **expérimental** et sujet à changement. Il pourrait être officiellement adopté à l’avenir. |
### _message_ VehiclePosition
@@ -440,7 +462,7 @@
### _message_ TripDescriptor
- Un descripteur qui identifie une instance unique d’un voyage GTFS.
+ Un descripteur qui identifie une instance unique d’un trajet GTFS, sauf si `schedule_relationship` est `NEW`, dans ce cas, il spécifie une nouvelle instance de trajet à ajouter.
Pour spécifier une seule instance de voyage, dans de nombreux cas, un `trip_id` à lui seul suffit. Cependant, les cas suivants nécessitent des informations supplémentaires pour être résolus en une seule instance de voyage :
@@ -455,13 +477,15 @@
Notez que si le trip_id n’est pas connu, alors les identifiants de séquence de stations dans TripUpdate ne sont pas suffisants et les stop_ids doivent également être fournis. De plus, les heures absolues d’arrivée/départ doivent être fournies.
TripDescriptor.route_id ne peut pas être utilisé dans un Alert EntitySelector pour spécifier une alerte à l’échelle de l’itinéraire qui affecte tous les trajets d’un itinéraire- utilisez EntitySelector.route_id à la place.
+
+ Si `schedule_relationship` est `NEW`, `trip_id` doit être défini sur une valeur non répertoriée dans le flux GTFS, et `route_id` doit être défini sur une valeur répertoriée dans `routes.txt` dans le statique GTFS, pour associer le trajet à un itinéraire. `start_date` doit être défini et `direction_id` peut être défini pour le nouveau trajet.
**Champs**
| _**Nom du champ**_ | _**Tapez**_ | _**Requis**_ | _**Cardinalité**_ | _**Description**_ |
|--------|------------|----------------|----------------------------------|-------------------|
- | **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Le trip_id du flux GTFS auquel ce sélecteur fait référence. Pour les déplacements non basés sur la fréquence (trajets non définis dans GTFS frequencies.txt), ce champ suffit à identifier de manière unique le déplacement. Pour les trajets basés sur la fréquence définis dans GTFS frequencies.txt, trip_id, start_time et start_date sont tous requis. Pour les trajets planifiés (trajets non définis dans GTFS frequencies.txt), trip_id ne peut être omis que si le trajet peut être identifié de manière unique par une combinaison de route_id, direction_id, start_time et start_date, et que tous ces champs sont fournis. Lorsque Schedule_relationship est DUPLICATED dans un TripUpdate, le trip_id identifie le voyage à partir du GTFS statique à dupliquer. Lorsque Schedule_relationship est DUPLICATED dans un VehiclePosition, le trip_id identifie le nouveau voyage en double et doit contenir la valeur du TripUpdate correspondant. TripProperties.trip_id. |
- | **route_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Le route_id du GTFS auquel ce sélecteur fait référence. Si trip_id est omis, route_id, direction_id, start_time et planning_relationship=SCHEDULED doivent tous être définis pour identifier une instance de voyage. TripDescriptor.route_id ne doit pas être utilisé dans un Alert EntitySelector pour spécifier une alerte à l’échelle de l’itinéraire qui affecte tous les trajets d’un itinéraire- utilisez EntitySelector.route_id à la place. |
+ | **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionnellement requis | Un | Le trip_id du flux GTFS auquel ce sélecteur fait référence. Pour les trajets non basés sur la fréquence (trajets non définis dans GTFS frequencies.txt), ce champ suffit à identifier de manière unique le trajet. Pour les trajets basés sur la fréquence définis dans GTFS frequencies.txt, trip_id, start_time et start_date sont tous obligatoires. Pour les trajets planifiés (trajets non définis dans le frequencies.txt de GTFS), trip_id ne peut être omis que si le trajet peut être identifié de manière unique par une combinaison de route_id, direction_id, start_time et start_date, et que tous ces champs sont fournis. Lorsque schedule_relationship est NEW, il doit être spécifié avec une valeur unique non définie dans le GTFS statique. Lorsque schedule_relationship est `REPLACEMENT`, trip_id identifie le trajet du GTFS statique à remplacer. Lorsque schedule_relationship est `DUPLICATED` dans un TripUpdate, trip_id identifie le trajet du GTFS statique à dupliquer. Lorsque schedule_relationship est `DUPLICATED` dans un VehiclePosition, trip_id identifie le nouveau trajet dupliqué et doit contenir la valeur du TripUpdate correspondant. TripProperties.trip_id. |
+ | **route_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Conditionnellement requis | Un | Le route_id du GTFS auquel ce sélecteur fait référence. Si trip_id est omis, route_id, direction_id, start_time et schedule_relationship=SCHEDULED doivent tous être définis pour identifier une instance de trajet. TripDescriptor.route_id ne doit pas être utilisé dans un EntitySelector d’alerte pour spécifier une alerte à l’échelle de l’itinéraire qui affecte tous les trajets d’un itinéraire- utilisez plutôt EntitySelector.route_id. Lorsque schedule_relationship est NEW, route_id doit être spécifié pour l’itinéraire auquel appartient le nouveau trajet. |
| **direction_id** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Le direction_id du fichier trips.txt du flux GTFS, indiquant la direction du déplacement pour les trajets auxquels ce sélecteur fait référence. Si trip_id est omis, direction_id doit être fourni.
**Attention :** ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
|
| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | Heure de début initialement prévue de cette instance de voyage. Lorsque le trip_id correspond à un voyage non basé sur la fréquence, ce champ doit être omis ou être égal à la valeur du flux GTFS. Lorsque le trip_id correspond à un trajet basé sur la fréquence défini dans GTFS frequencies.txt, start_time est requis et doit être spécifié pour les mises à jour du trajet et les positions des véhicules. Si le trajet correspond à l’enregistrement GTFS exact_times=1, alors start_time doit être un multiple (y compris zéro) de headway_secs après frequencies.txt start_time pour la période correspondante. Si le trajet correspond à exact_times=0, alors son heure de début peut être arbitraire et devrait initialement être le premier départ du voyage. Une fois établi, le start_time de ce trajet exact_times=0 basé sur la fréquence doit être considéré comme immuable, même si la première heure de départ change- ce changement d’heure peut plutôt être reflété dans un StopTimeUpdate. Si trip_id est omis, start_time doit être fourni. Le format et la sémantique du champ sont les mêmes que ceux de GTFS/frequencies.txt/start_time, par exemple 11:15:35 ou 25:15:35. |
| **start_date** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis sous condition | Un | La date de début de cette instance de voyage au format AAAAMMJJ. Pour les trajets programmés (trajets non définis dans GTFS frequencies.txt), ce champ doit être fourni pour lever l’ambiguïté des trajets qui sont si tardifs qu’ils entrent en collision avec un trajet programmé le jour suivant. Par exemple, pour un train qui part à 8h00 et à 20h00 tous les jours et qui a 12 heures de retard, il y aurait deux trajets distincts à la même heure. Ce champ peut être fourni mais n’est pas obligatoire pour les horaires dans lesquels de telles collisions sont impossibles- par exemple, un service fonctionnant selon un horaire horaire où un véhicule en retard d’une heure n’est plus considéré comme étant lié à l’horaire. Ce champ est obligatoire pour les trajets basés sur la fréquence définis dans GTFS frequencies.txt. Si trip_id est omis, start_date doit être fourni. |
@@ -470,17 +494,19 @@
### _enum_ ScheduleRelationship
- La relation entre ce trajet et l’horaire statique. Si un voyage est effectué conformément à un horaire temporaire, non reflété dans GTFS, il ne doit pas être marqué comme PLANIFIÉ, mais comme AJOUTÉ.
+ La relation entre ce trajet et le planning statique. Si un nouveau trajet est effectué conformément à un planning temporaire, non reflété dans GTFS, il ne doit pas être marqué comme PROGRAMMÉ, mais marqué comme NOUVEAU. Si un trajet est effectué conformément à un planning modifié, non reflété dans GTFS, il ne doit pas être marqué comme « `SCHEDULED` », mais marqué comme « REMPLACEMENT ».
**Valeurs**
| _**Valeur**_ | _**Commentaire**_ |
|-------------|--------------------|
| **SCHEDULED** | Voyage qui se déroule conformément à son horaire GTFS ou qui est suffisamment proche du voyage planifié pour y être associé. |
- | **ADDED** | Un trajet supplémentaire qui a été ajouté en plus d’un horaire de course, par exemple pour remplacer un véhicule en panne ou pour répondre à un afflux soudain de passagers. *REMARQUE : actuellement, le comportement n’est pas spécifié pour les flux qui utilisent ce mode. Il y a des discussions sur le GTFS GitHub [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221 ) [(3)](https://github.com/google/transit/pull/219) autour de la spécification complète ou de la dépréciation des voyages AJOUTÉS et la documentation sera mise à jour lorsque ces discussions seront finalisées.* |
+ |**ADDED**| *REMARQUE : Cette valeur est obsolète car le comportement n’était pas spécifié. Utilisez **DUPLICATED** pour un trajet supplémentaire identique à un trajet planifié, à l’exception de la date ou de l’heure de début, ou **NEW** pour un trajet supplémentaire sans rapport avec un trajet existant.* |
| **UNSCHEDULED** | Un voyage en cours sans horaire associé - cette valeur est utilisée pour identifier les voyages définis dans GTFS frequencies.txt avec exact_times = 0. Elle ne doit pas être utilisée pour décrire des voyages non définis dans GTFS frequencies.txt ou des voyages dans GTFS. frequencies.txt avec exact_times = 1. Les trajets avec `schedule_relationship: UNSCHEDULED` doivent également définir toutes les StopTimeUpdates `schedule_relationship: UNSCHEDULED`|
| **CANCELED** | Un voyage qui existait dans le planning mais qui a été supprimé. |
+ |**REMPLACEMENT**| Un trajet qui remplace un trajet planifié existant, par exemple avec un horaire modifié ou un itinéraire dévié. Le trajet complet du trajet de remplacement doit être spécifié via « `StopTimeUpdate`», et le planning d’origine du fichier statique GTFS n’est pas utilisé pour l’instance remplacée.
« REPLACEMENT » peut être utilisé si le voyage fonctionne selon un horaire révisé, mais ne doit pas être utilisé pour communiquer des écarts d’horaire en temps réel (prédictions) si le véhicule est censé suivre l’horaire répertorié dans « `stop_times.txt` » le GTFS statique.
**Attention**: ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté ultérieurement. |
| **DUPLICATED** | Un nouveau trajet identique à un trajet programmé existant, à l’exception de la date et de l’heure de début du service. Utilisé avec `TripUpdate.TripProperties.trip_id`, `TripUpdate.TripProperties.start_date` et `TripUpdate.TripProperties.start_time` pour copier un voyage existant à partir de GTFS statique mais commencer à une date et/ou une heure de service différente. La duplication d’un voyage est autorisée si le service lié au voyage d’origine au format (CSV) GTFS (dans `calendar.txt` ou `calendar_dates.txt`) fonctionne dans les 30 prochains jours. Le voyage à dupliquer est identifié via `TripUpdate.TripDescriptor.trip_id`.
Cette énumération ne modifie pas le voyage existant référencé par `TripUpdate.TripDescriptor.trip_id` - si un producteur souhaite annuler le voyage d’origine, il doit publier un `TripUpdate` séparé avec la valeur CANCELED. Les trajets définis dans GTFS `frequencies.txt` avec `exact_times` vide ou égal à `0` ne peuvent pas être dupliqués. Le `VehiclePosition.TripDescriptor.trip_id` pour le nouveau voyage doit contenir la valeur correspondante de `TripUpdate.TripProperties.trip_id` et `VehiclePosition.TripDescriptor.ScheduleRelationship` doit également être défini sur `DUPLICATED`.
*Les producteurs et consommateurs existants qui utilisaient l’énumération ADDED pour représenter les voyages en double doivent suivre le [guide de migration](../../realtime/examples//migration-duplicated) pour passer à l’énumération DUPLICATED.* |
+ | **NEW** | Un trajet supplémentaire, sans rapport avec les trajets existants, par exemple pour répondre à une augmentation soudaine du nombre de passagers. Le trajet complet du nouveau trajet, y compris tous les arrêts et les horaires, doit être spécifié via « `StopTimeUpdate`».
*Les producteurs et consommateurs existants qui utilisaient l’énumération « `ADDED` » pour représenter de nouveaux trajets non liés au GTFS statique doivent suivre le [guide de migration](../../realtime/examples//migration-duplicated) pour passer à la ADDED énumération.*
**Attention**: ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté ultérieurement. |
| **DELETED** | Un trajet qui existait dans le planning mais qui a été supprimé et qui ne doit pas être montré aux utilisateurs.
DELETED doit être utilisé au lieu de CANCELED pour indiquer qu’un fournisseur de transport souhaite supprimer entièrement les informations sur le trajet correspondant des applications consommatrices, afin que le trajet ne soit pas affiché comme annulé aux usagers, par exemple un trajet qui est entièrement remplacé par un autre trajet. Cette désignation devient particulièrement importante si plusieurs voyages sont annulés et remplacés par un service de substitution. Si les consommateurs devaient afficher des informations explicites sur les annulations, cela les détournerait des prévisions en temps réel les plus importantes.
**Attention :** ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
## _message_ ModifiedTripSelector
@@ -591,7 +617,7 @@ Lorsqu’un service est affecté par une modification de trajet, `ModifiedTripSe
| _**Nom du champ**_ | _**Tapez**_ | _**Requis**_ | _**Cardinalité**_ | _**Description**_ |
|--------|------------|----------------|----------------------------------|-------------------|
| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis | Un | Identificateur de la forme. Doit être différent de tout « `shape_id` » défini dans le GTFS (CSV).
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
- | **encoded_polyline** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis | Un | Représentation polyligne codée de la forme. Cette polyligne doit contenir au moins deux points. Pour plus d’informations sur les polylignes codées, consultez https://developers.google.com/maps/documentation/utilities/polylinealgorithm
**Attention :**ce champ est encore **expérimental** et est susceptible de changer. Il pourrait être formellement adopté à l’avenir. |
+ | **encoded_polyline** | [string](https:) | Requis | Un | Représentation polyligne codée de la forme. Cette polyligne doit contenir au moins deux points et représenter la forme complète du trajet où elle est utilisée. Pour plus d’informations sur les polylignes codées, consultez https://developers.google.com/maps/documentation/utilities/polylinealgorithm
**Attention :**ce champ est encore **expérimental** et sujet à modification. Il pourrait être officiellement adopté à l’avenir. |
### _message_ Stop
@@ -694,8 +720,8 @@ Lorsqu’un service est affecté par une modification de trajet, `ModifiedTripSe
| _**Nom du champ**_ | _**Tapez**_ | _**Requis**_ | _**Cardinalité**_ | _**Description**_ |
|--------|------------|----------------|----------------------------------|-------------------|
- | **trip_ids** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Plusieurs | Un | Une liste des trip_id du GTFS d’origine (CSV) qui sont affectés par le remplacement contenant. Doit contenir au moins un trip_id. |
- | **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis | Un | ID de la nouvelle forme pour les trajets modifiés dans ce SelectedTrips. Peut faire référence à une nouvelle forme ajoutée à l’aide d’un message GTFS-RT Shape ou à une forme existante définie dans le fichier shapes.txt du flux GTFS-Static. |
+ | **trip_ids** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | Plusieurs | Un | Une liste de trip_id du GTFS d’origine (CSV) qui sont affectés par le remplacement contenant. Doit contenir au moins un trip_id. Un `TripUpdate` avec `schedule_relationship=REPLACEMENT` ne doit pas déjà exister pour le voyage. |
+| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis | Un | L’ID de la nouvelle forme pour les trajets modifiés dans ce SelectedTrips. Peut faire référence à une nouvelle forme ajoutée à l’aide d’un message « `Shape` » dans le même flux GTFS-RT, ou à une forme existante définie dans le fichier shapes.txt du flux GTFS-Static. S’il fait référence à une entité « `Shape` » dans le flux en temps réel, la valeur de ce champ doit être celle de « `shape_id` » dans l’entité, et non celle de « `id` » de « `FeedEntity` ». |
### _message_ ReplacementStop
@@ -712,6 +738,6 @@ Lorsqu’un service est affecté par une modification de trajet, `ModifiedTripSe
| _**Nom du champ**_ | _**Tapez**_ | _**Requis**_ | _**Cardinalité**_ | _**Description**_ |
|--------|------------|----------------|----------------------------------|-------------------|
- | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis | Un | L’identifiant de l’arrêt de remplacement qui sera désormais visité par le voyage. Peut faire référence à un nouvel arrêt ajouté à l’aide d’un message`Stop` GTFS-RT, ou à un arrêt existant défini dans le `stops.txt` du flux GTFS (CSV). L’arrêt DOIT avoir `location_type=0` (arrêts routables). |
+ | **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | Requis | Un | L’ID d’arrêt de remplacement qui sera désormais visité par le trajet. Peut faire référence à un nouvel arrêt ajouté via un message « Stop » GTFS-RT dans le même flux GTFS-RT, ou à un arrêt existant défini dans le fichier « `stops.txt` » du flux GTFS (CSV). S’il fait référence à une entité « `Shape` » dans le flux en temps réel, la valeur de ce champ doit correspondre à l’identifiant « `stop_id` » de l’entité, et non à l’ `id` « `FeedEntity` ». L’arrêt DOIT avoir « `location_type=0` » (arrêts routables). |
| **travel_time_to_stop** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | Optionnel | Un | La différence en secondes entre l’heure d’arrivée à cet arrêt et l’heure d’arrivée à l’arrêt de référence. L’arrêt de référence est l’arrêt précédant `start_stop_selector`. Si la modification commence au premier arrêt du trajet, alors le premier arrêt du trajet est l’arrêt de référence.
Cette valeur DOIT être croissante de manière monotone et ne peut être qu’un nombre négatif si le premier arrêt du trajet d’origine est l’arrêt de référence.
Si la valeur n’est pas fournie, les consommateurs PEUT interpoler ou déduire le « travel_time_to_stop » sur la base d’autres données. |
\ No newline at end of file
diff --git a/docs/ja/documentation/realtime/change-history/revision-history.md b/docs/ja/documentation/realtime/change-history/revision-history.md
index 14ba0a483..81b1e52d1 100644
--- a/docs/ja/documentation/realtime/change-history/revision-history.md
+++ b/docs/ja/documentation/realtime/change-history/revision-history.md
@@ -2,6 +2,11 @@
### 改訂履歴
+#### 2025年5月
+
+* スケジュール関係の `ADDED` を廃止し、代わりに `NEW` を導入し、`REPLACEMENT` を追加しました。[ディスカッション](https://github.com/google/transit/pull/504) をご覧ください。
+* 旅程の変更に関する説明を追加しました。[ディスカッション](https://github.com/google/transit/pull/542) をご覧ください。
+
#### 2024年12月
* リアルタイム データのベースとなるGTFS Scheduleフィードの feed_info.feed_version に一致する新しいstringフィールドを追加しました。 [ディスカッション](https://github.com/google/transit/pull/434) を参照してください。
diff --git a/docs/ja/documentation/realtime/examples/migration-duplicated.md b/docs/ja/documentation/realtime/examples/migration-duplicated.md
index 4fb283b23..6627c2d5f 100644
--- a/docs/ja/documentation/realtime/examples/migration-duplicated.md
+++ b/docs/ja/documentation/realtime/examples/migration-duplicated.md
@@ -1,13 +1,74 @@
-## 移行ガイド - ADDED から DUPLICATED の便への移行
+## 移行ガイド - ADDED から NEW または DUPLICATED の便への移行
+
+GTFS リアルタイムの `trip.schedule_relationship` が `NEW` の場合、既存の定期旅程とは無関係のスケジュールで運行される新しい旅程を表します。
GTFS リアルタイムの `trip.schedule_relationship` の `DUPLICATED` は、サービス開始日時を除いて既存のスケジュールされた便と同じ新しい便を表します。
-この移行ガイドでは、重複した便を表すために `ADDED` 列挙を使用していた既存のプロデューサーとコンシューマーが `DUPLICATED` 列挙に移行する方法を定義します。目標は、移行中にプロデューサーとコンシューマーの混乱を最小限に抑えることです。
+この移行ガイドでは、 `ADDED`列挙を使用していた既存のプロデューサーとコンシューマーが、`NEW` または`DUPLICATED`列挙に移行するべきである方法を定義します。移行中のプロデューサーとコンシューマーの混乱を最小限に抑えることが目標です。
+
+* `ADDED` `ADDED`列挙型を**使用していない**プロデューサーまたはコンシューマーの場合、何もする必須はありません。`ADDED` エンティティを生成/消費することなく、`NEW` または`DUPLICATED` の便を生成/消費できます。*
-*重複した便を表すために `ADDED` 列挙を **使用していない** プロデューサーまたはコンシューマーの場合、アクションは必要ありません。`ADDED` エンティティを生成/消費することなく、`DUPLICATED` 便を生成/消費できます。*
+`NEW` 列挙型の完全な履歴については、[GitHub の `NEW` および `REPLACEMENT` 提案](https://github.com/google/transit/pull/504) をご覧ください。
`DUPLICATED` 列挙の完全な履歴については、[GitHub の `DUPLICATED` 提案](https://github.com/google/transit/pull/221) をご覧ください。
+### どちらに移行するか
+
+`NEW`列挙型と`DUPLICATED`列挙型はどちらも、元々 GTFS 静的に実行がスケジュールされていなかった旅行を指定するために使用されます。
+
+`NEW` を使用する予定されて便をテンプレートとして使用して旅行を説明できない場合。たとえば、ルートの通常の便とは異なる停留所に寄る場合や、通常の便ではすべての停留所で乗車と降車の両方が許可されているのに、追加の旅行ではルートの開始時にのみ乗車する場合などです。
+
+旅行がスケジュール済みの旅行のコピーである場合は、 `DUPLICATED` を使用します。このコピーは、元のスケジュール済みの旅行と同じ時間、または異なる時間に実行されるしてもよい。
+
+### 同じフィードで ADDED エンティティと NEW エンティティを使用する
+
+スケジュールに関係のない旅行を指定するために `ADDED` 列挙を使用しているプロデューサーの場合は、既存のコンシューマーの混乱を避けるために、これらの旅行に対して `ADDED` エンティティを引き続き生成し、同じ旅行に対して `NEW` エンティティも追加することをお勧めします。
+
+ただし、コンシューマーが誤って同じ旅行を 2 回追加するのを防ぐために、同じ旅行を参照するエンティティは、同じ`trip_id`、 `route_id` 、および`start_date`を使用してリンクされているしなければならない。
+さらに、コンテンツ`stop_time_update`も同じであるしなければならない。
+
+#### プロデューサー
+
+~~~
+entity {
+ ID: "ei0"
+ trip_update {
+ trip: {
+ trip_id: "1"//<-- 静的 GTFS に見つからないtrip_id route_id: "A"
+ schedule_relationship: ADDED
+ start_date: "20200821"//<-- 新しい旅行date
+ start_time: "11:30:00"//<-- 新しい旅行時刻
+ }
+ stop_time_update {
+...//旅行の停車地点の完全なリスト
+ }
+ }
+}
+
+entity {
+ ID: "ei10"
+ trip_update {
+ trip: {
+ trip_id: "1"//<-- 上記と同じtrip_id route_id: "A"//<-- 上記と同じroute_id : NEW
+ start_date: "20200821"//<-- 上記と同じdate
+ start_time: "11:30:00"//<-- 上記と同じ時刻
+ }
+ stop_time_update {
+...//<-- 上記と同じコンテンツ
+ }
+ }
+}
+~~~
+
+既存のコンシューマーに対して、設定された期限までに`ADDED`の使用が廃止され、代わりに `NEW`便の使用を開始するするべきであることを通知することをお勧めします (開発者メーリング リストなど経由)。`ADDED`と`NEW` 旅行エンティティを一致させるために使用されている上記の戦略についても言及するべきである、この移行ガイドへのリンクを含めるするべきである。期限が過ぎると、フィードから `ADDED` エンティティを削除し、新しく追加された便の `NEW` エンティティのみを公開できます。
+
+#### コンシューマー
+
+前述のように、プロデューサーは、最初に同じ`trip_id`に` 2 つのエンティティを公開することにより、 `ADDED`列挙から `NEW` 列挙に移行します。
+
+したがって、コンシューマーが `NEW`便のサポートを実装する場合、コンシューマーが `NEW` 旅行の`trip_id`を持つ`trip_id` `ADDED`便を無視することが重要です。
+
+
### 同じフィードでの ADDED エンティティと DUPLICATED エンティティの使用
#### プロデューサー
@@ -93,7 +154,7 @@ entity {
}
~~~
-既存のコンシューマーに、設定された期限までに重複した便に対する `ADDED` の使用が廃止され、代わりに `DUPLICATED` 便の使用を開始するよう通知することをお勧めします (開発者のメーリング リストなど)。`ADDED` と `DUPLICATED` 便エンティティを一致させるために使用されている上記の戦略についても言及し、この移行ガイドへのリンクを含める必要があります。期限が過ぎたら、フィードから `ADDED` エンティティを削除し、重複した便に対して `DUPLICATED` エンティティのみを公開できます。
+既存のコンシューマー（開発者メーリングリストなど）に、 `ADDED`の使用は期限までに廃止され、代わりに`ADDED` `DUPLICATED` の便を使用するするべきであることを通知することをお勧めします。`ADDED` と ` `DUPLICATED` の旅行エンティティを一致させるために使用されている上記の戦略についても言及するべきである、この移行ガイドへのリンクを含めるするべきである。期限が過ぎると、フィードから`ADDED`エンティティを削除し、重複した便の`DUPLICATED`エンティティのみを公開できます。
#### コンシューマー
diff --git a/docs/ja/documentation/realtime/feed-entities/trip-updates.md b/docs/ja/documentation/realtime/feed-entities/trip-updates.md
index 8f7f72b3c..2197227cb 100644
--- a/docs/ja/documentation/realtime/feed-entities/trip-updates.md
+++ b/docs/ja/documentation/realtime/feed-entities/trip-updates.md
@@ -13,7 +13,7 @@
## StopTimeUpdate
-ルート更新は、車両の停車時刻に対する 1 つ以上の更新で構成されます。これは [StopTimeUpdates](../../reference/#message-stoptimeupdate) と呼ばれます。これらは、過去および将来の停車時刻に対して指定できます。過去の停車時刻を削除できますが、削除は必須ではありません。プロデューサーは、過去の`StopTimeUpdate`が、特定の旅程で予定到着時刻が未来の停留所を参照している場合（つまり、車両が予定より早く停留所を通過している場合）、それを削除するべきではない。削除すると、この停留所には更新がないと判断されます。
+ルート更新は、車両の停車時刻に対する 1 つ以上の更新で構成されます。これは [StopTimeUpdates](../../reference/#message-stoptimeupdate) と呼ばれます。これらは、過去と未来の停車時刻について提供できます。GTFSスタティックに見つからない新しい旅程または代替の旅程でない限り、過去の停車時刻を削除できますが、必須ではありません。過去の`StopTimeUpdate`が、特定の旅程の到着予定時刻が未来の停車時刻である（つまり、車両が予定より早く停車地を通過した）停車時刻を参照している場合、プロデューサーはそれを削除しないでください。そうしないと、この停車時刻の更新がないと判断されます。
たとえば、GTFS-rt フィードに次のデータが表示される場合:
diff --git a/docs/ja/documentation/realtime/gtfs-realtime.proto b/docs/ja/documentation/realtime/gtfs-realtime.proto
index 34a8a20ab..e050fc19f 100644
--- a/docs/ja/documentation/realtime/gtfs-realtime.proto
+++ b/docs/ja/documentation/realtime/gtfs-realtime.proto
@@ -195,6 +195,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -277,6 +284,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -374,16 +407,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -798,14 +838,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -814,8 +850,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -824,7 +861,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -844,6 +884,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -869,8 +913,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1051,7 +1095,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1139,10 +1183,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1200,7 +1245,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
diff --git a/docs/ja/documentation/realtime/proto.md b/docs/ja/documentation/realtime/proto.md
index 596de4dc0..34e9b9ebf 100644
--- a/docs/ja/documentation/realtime/proto.md
+++ b/docs/ja/documentation/realtime/proto.md
@@ -200,6 +200,13 @@ message TripUpdate {
// To specify a completely certain prediction, set its uncertainty to 0.
optional int32 uncertainty = 3;
+ // Scheduled time for a NEW, REPLACEMENT, or DUPLICATED trip.
+ // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00
+ // UTC).
+ // Optional if TripUpdate.schedule_relationship is NEW, REPLACEMENT or DUPLICATED, forbidden otherwise.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional int64 scheduled_time = 4;
+
// 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.
@@ -282,6 +289,32 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string assigned_stop_id = 1;
+ // The updated headsign of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string stop_headsign = 2;
+
+ enum DropOffPickupType {
+ // Regularly scheduled pickup/dropoff.
+ REGULAR = 0;
+
+ // No pickup/dropoff available
+ NONE = 1;
+
+ // Must phone agency to arrange pickup/dropoff.
+ PHONE_AGENCY = 2;
+
+ // Must coordinate with driver to arrange pickup/dropoff.
+ COORDINATE_WITH_DRIVER = 3;
+ }
+
+ // The updated pickup of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType pickup_type = 3;
+
+ // The updated drop off of the vehicle at the stop.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional DropOffPickupType drop_off_type = 4;
+
// 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.
@@ -379,16 +412,23 @@ message TripUpdate {
// populated and will be ignored by consumers.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string start_time = 3;
- // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in
- // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing
- // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS
- // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt
- // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as
- // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should
- // be marked as schedule_relationship=SKIPPED.
+ // Specifies the identifier of the shape of the vehicle travel path when the trip shape differs from the shape specified in (CSV) GTFS
+ // or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS.
+ // If a shape is neither defined in (CSV) GTFS nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt or a `Shape` in the same (protobuf) real-time feed.
+ // The order of stops (stop sequences) for this trip must remain the same as (CSV) GTFS.
+ // If it refers to a `Shape` entity in the same real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
+ // Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should be marked as schedule_relationship=SKIPPED or more details can be provided via a `TripModifications` message.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 4;
+ // Specifies the headsign for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_headsign = 5;
+
+ // Specifies the name for this trip when it differs from the original.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ optional string trip_short_name = 6;
+
// 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.
@@ -803,14 +843,10 @@ message TripDescriptor {
// enough to the scheduled trip to be associated with it.
SCHEDULED = 0;
- // 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.
- // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub
- // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221)
- // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the
- // documentation will be updated when those discussions are finalized.
- ADDED = 1;
+ // This value has been deprecated as the behavior was unspecified.
+ // Use DUPLICATED for an extra trip that is the same as a scheduled trip except the start date or time,
+ // or NEW for an extra trip that is unrelated to an existing trip.
+ ADDED = 1 [deprecated = true];
// A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0).
// Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED.
@@ -819,8 +855,9 @@ message TripDescriptor {
// A trip that existed in the schedule but was removed.
CANCELED = 3;
- // Should not be used - for backwards-compatibility only.
- REPLACEMENT = 5 [deprecated = true];
+ // A trip that replaces an existing trip in the schedule.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ REPLACEMENT = 5;
// 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. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date,
@@ -829,7 +866,10 @@ message TripDescriptor {
// (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is
// identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by
// TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate
- // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is
+ // TripUpdate with the value of CANCELED or DELETED. If a producer wants to replace the original trip, a value of
+ // `REPLACEMENT` should be used instead.
+ //
+ // Trips defined in GTFS frequencies.txt with exact_times that is
// empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain
// the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship
// must also be set to DUPLICATED.
@@ -849,6 +889,10 @@ message TripDescriptor {
// real-time predictions.
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
DELETED = 7;
+
+ // An extra trip unrelated to any existing trips, for example, to respond to sudden passenger load.
+ // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
+ NEW = 8;
}
optional ScheduleRelationship schedule_relationship = 4;
@@ -874,8 +918,8 @@ message TripDescriptor {
extensions 9000 to 9999;
}
- // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
- // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
+ // Linkage to any modifications done to this trip (shape changes, removal or addition of stops).
+ // If this field is provided, the `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` fields of the `TripDescriptor` MUST be left empty, to avoid confusion by consumers that aren't looking for the `ModifiedTripSelector` value.
optional ModifiedTripSelector modified_trip = 7;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1056,7 +1100,7 @@ message Shape {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string shape_id = 1;
- // Encoded polyline representation of the shape. This polyline must contain at least two points.
+ // Encoded polyline representation of the shape. This polyline must contain at least two points and represent the full shape of the trip where it's used.
// For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm
// This field is required as per reference.md, but needs to be specified here optional because "Required is Forever"
// See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules
@@ -1144,10 +1188,11 @@ message TripModifications {
}
message SelectedTrips {
- // A list of trips affected with this replacement that all have the same new `shape_id`.
+ // A list of trips affected with this replacement that all have the same new `shape_id`. A `TripUpdate` with `schedule_relationship=REPLACEMENT` must not already exist for the trip.
repeated string trip_ids = 1;
- // The ID of the new shape for the modified trips in this SelectedTrips.
- // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // The ID of the new shape for the modified trips in this SelectedTrips.
+ // May refer to a new shape added using a `Shape` message in the same GTFS-RT feed, or to an existing shape defined in the GTFS-Static feed’s shapes.txt.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `shape_id` inside the entity, and _not_ the `id` of `FeedEntity`.
optional string shape_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
@@ -1205,7 +1250,8 @@ message ReplacementStop {
// This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop.
optional int32 travel_time_to_stop = 1;
- // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops).
+ // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT `Stop` message in the same GTFS-RT feed, or to an existing stop defined in the (CSV) GTFS feed’s `stops.txt`.
+ // If it refers to a `Shape` entity in the real-time feed, the value of this field should be the one of the `stop_id` inside the entity, and _not_ the `id` of `FeedEntity`. The replacement stop MUST have `location_type=0` (routable stops).
optional string stop_id = 2;
// The extensions namespace allows 3rd-party developers to extend the
diff --git a/docs/ja/documentation/realtime/realtime-best-practices.md b/docs/ja/documentation/realtime/realtime-best-practices.md
index 9e8e0dee2..6c192c49b 100644
--- a/docs/ja/documentation/realtime/realtime-best-practices.md
+++ b/docs/ja/documentation/realtime/realtime-best-practices.md
@@ -46,7 +46,7 @@
便キャンセルに関する一般的なガイドライン:
* 数日間にわたる便をキャンセルする場合、プロデューサーは、指定された `trip_ids` と `start_dates` を `CANCELED` として参照する TripUpdates と、同じ `trip_ids` と `TimeRange` を参照する `NO_SERVICE` を含む Alert を提供して、乗客にキャンセルの理由 (迂回など) を説明する必要があります。
-* 便中に停留所が 1 つも訪問されない場合は、すべての `stop_time_updates` を `SKIPPED` としてマークするのではなく、便を `CANCELED` にする必要があります。
+* 旅程で停留所を訪問しない場合は、すべての`stop_time_updates`を`SKIPPED`としてマークするのではなく、その旅程を`CANCELED` にするするべきである。ただし、その旅程が `NEW` または`DUPLICATED`旅程で、その後キャンセルされた場合は除きます。
| フィールド名 | 推奨事項 |
|---|---|
@@ -67,7 +67,13 @@
| フィールド名 | 推奨事項 |
|---|---|
-| `schedule_relationship` | `ADDED`便の動作は指定されていないため、この列挙体の使用は推奨ません。 |
+| `schedule_relationship` | `ADDED`便の動作は指定されていないため、この列挙体の使用は推奨ません。
旅行が元々実行予定でない場合、既存の旅行の停車パターンに従わない場合は `NEW` を使用し、既存の旅行のコピーの場合は`DUPLICATED` を使用します。
旅行が変更されたスケジュールで運行または停留所が、GTFS 静的ファイル内の元のスケジュール済みの旅行に関連付けるするべきである場合は、`REPLACEMENT` を使用して、変更された旅行の停車時刻の完全なリストを指定します。 |
+
+### TripProperties
+
+| フィールド名 | 推奨事項 |
+|---|---|
+| `trip_headsign` | ` TripDescriptor.schedule_relationship` = `NEW` の旅行には常に指定し、旅行が迂回する場合は `TripDescriptor.schedule_relationship` = `REPLACEMENT` の旅行に指定します。 |
### VehicleDescriptor
@@ -95,6 +101,7 @@
| フィールド名 | 推奨事項 |
|---|---|
| `delay` | `stop_time_update`の`arrival`または`departure`で`delay`のみが指定されている場合 ( `time`は指定されていない場合)、GTFS [`stop_times.txt`](../../schedule/reference/#stop_timestxt) には、これらの対応する停留所等の`arrival_times`および/または`departure_times`が含まれているするべきである。リアルタイム フィード内の`delay`値は、GTFS `stop_times.txt`ファイルに追加するための時刻がない限り、意味がありません。 |
+| `scheduled_time` |新規または代替の旅程で、スケジュールに従って運行される場合（代替旅程の場合は変更されたスケジュールでも構いません）、すべての時点に`scheduled_time`を指定するするべきである。複製された旅程の運行時間が元の運行時間と異なる場合も、`scheduled_time`を使用してそれらを指定することができます。|
### VehiclePosition
diff --git a/docs/ja/documentation/realtime/reference.md b/docs/ja/documentation/realtime/reference.md
index 0621df44a..9badd772a 100644
--- a/docs/ja/documentation/realtime/reference.md
+++ b/docs/ja/documentation/realtime/reference.md
@@ -19,6 +19,7 @@ GTFS リアルタイム v2.0 以降では、*必須* 列は、交通事業者デ
* **必須**: このフィールドは、GTFS リアルタイム フィード プロデューサーが提供するしなければならない。
* **条件付きで必須**: このフィールドは、フィールド *説明* で概説されている特定の条件下では必須です。これらの条件以外では、フィールドは任意です。
+* **条件付きで禁止**: このフィールドは、*説明*フィールドに記載されている特定の条件下では禁止されています。これらの条件以外では、フィールドは任意です。
* **任意**: このフィールドは任意であり、プロデューサーが実装する必須はありません。ただし、基礎となる自動車両位置システム（例： VehiclePosition `timestamp` ）でデータが利用可能な場合は、可能であればプロデューサーがこれらの任意フィールドを提供することが推奨 *セマンティック要件は GTFS リアルタイム バージョン 1.0 では定義されていないため、`gtfs_realtime_version`が`1`のフィードはこれらの要件を満たさないしてもよいがあることに注意してください（詳細については、[セマンティック要件の提案](https://github.com/google/transit/pull/64)を参照してください）。*
### カーディナリティ
@@ -150,6 +151,7 @@ ScheduleRelationship の値に応じて、TripUpdate では以下を指定でき
* スケジュールに沿って進む便。
* ルートに沿って進むが、スケジュールは固定されていない便。
* スケジュールに関して追加または削除された便。
+* 静的 GTFS 内の既存の旅程を置き換える旅程。
* 静的 GTFS の既存の便のコピーである新しい便。TripProperties で指定されたサービス日時で実行されます。
更新は、将来の予測到着/出発イベント、またはすでに発生した過去のイベントに対して行うことができます。ほとんどの場合、過去のイベントに関する情報は測定値であるため、その不確実性の値は 0 にすることを推奨。ただし、これが当てはまらない場合もあり、その場合は過去のイベントの不確実性の値が 0 以外になることが許可されます。更新の不確実性が 0 でない場合、更新は完了していない便のおおよその予測であるか、測定が正確でないか、更新はイベント発生後に検証されていない過去の予測であったかのいずれかです。
@@ -167,17 +169,18 @@ ScheduleRelationship の値に応じて、TripUpdate では以下を指定でき
|------------------|-----------|----------------|-------------------|-------------------|
| **trip** | [TripDescriptor](#message-tripdescriptor) | 必須 | 1つ | このmessageが適用される便。実際の便インスタンスごとに最大 1つのTripUpdateエンティティが存在します。存在しない場合は、予測情報が利用できないことを意味します。便がスケジュールどおりに進んでいることを意味するわけではありません。 |
| **vehicle** | [VehicleDescriptor](#message-vehicledescriptor) |任意| 1つ | この便にサービスを提供する車両に関する追加情報。 |
-| **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) |条件付きで必須| 複数 | 便の StopTimes の更新 (将来の予測と、場合によっては過去の停止時刻、つまりすでに発生した停止時刻の両方)。更新はstop_sequenceで並べ替えるしなければならないがあり、次に指定された stop_time_update までの便のすべての後続の停留所等に適用する必要があります。 trip.schedule_relationship が CANCELED、DELETED、または DUPLICATED でない限り、少なくとも 1つの stop_time_update を便に指定するしなければならないがあります。便がキャンセルまたは削除された場合は、stop_time_updates を指定する必要はありません。キャンセルまたは削除された便に stop_time_updates が指定されている場合、trip.schedule_relationship は、stop_time_updates および関連する schedule_relationship よりも優先されます。便が重複している場合は、新しい便のリアルタイム情報を示すために stop_time_updates を指定してもよい。|
+|**stop_time_update**| [StopTimeUpdate](#message-stoptimeupdate) |条件付きで必須| 多数 | 旅程の StopTimes の更新（将来の予測と、場合によっては過去の停止時刻（すでに発生したもの）の両方）。更新はstop_sequenceで並べ替え、次に指定された stop_time_update までの旅程の後続のすべての停留所に適用するしなければならない。
trip.schedule_relationship が SCHEDULED または UNSCHEDULED の場合、旅行に対して少なくとも 1 つの stop_time_update を指定するしなければならない。
trip.schedule_relationship が `NEW` または `REPLACEMENT` の場合、過去の時刻の停留所も含め、新規または代替の旅程のすべての停留所に対して stop_time_updates を指定するしなければならないがあり、静的 GTFS の停車時刻は使用されません。
旅程がキャンセルまたは削除された場合、stop_time_updates を指定する必要はありません。キャンセルまたは削除された旅程に stop_time_updates が指定されている場合、trip.schedule_relationship は、stop_time_updates および関連する Schedule_relationship よりも優先されます。旅程が重複している場合は、新しい旅程のリアルタイム情報を示すために stop_time_updates を指定してもよい。|
| **timestamp** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 将来の StopTimes を推定するために車両のリアルタイムの進行状況が測定された最新の瞬間。過去の StopTimes が指定されている場合、到着/出発時刻はこの値よりも早くなるしてもよい。 POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。 |
| **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 便の現在のスケジュールの偏差。遅延は、予測が GTFS の既存のスケジュールと比較して指定される場合にのみ指定するするべきである。
遅延 (秒単位) は、正 (車両が遅れていることを意味する) または負 (車両が予定より進んでいることを意味する) になります。遅延が 0 の場合、車両は正確に時間通りであることを意味します。
StopTimeUpdates の遅延情報は、便レベルの遅延情報よりも優先されるため、便レベルの遅延は、 StopTimeUpdate遅延値が指定された便の次の停留所までのみ伝播されます。
フィード プロバイダーは、データの鮮度を評価するために、遅延値が最後に更新された日時を示すTripUpdate.timestamp 値を提供することを強くお勧めします。
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
| **trip_properties** | [TripProperties](#message-tripproperties) | 任意 | 1つ | 便の更新されたプロパティを提供します。
**注意:** このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 |
### _message_ StopTimeEvent
-単一の予測イベント (到着または出発) のタイミング情報。タイミングは、遅延および/または推定時間、および不確実性で構成されます。
+単一の予測イベント（到着または出発）の時刻情報。時刻は、遅延および／または推定時刻、および不確実性で構成されます。 `NEW`、`REPLACEMENT`、または`DUPLICATED` の便にもスケジュール時刻を追加できます。
* 遅延は、GTFS の既存のスケジュールを基準にして予測が示される場合に使用するべきである。
-* 時間は、予測スケジュールがあるかどうかに関係なく指定するするべきである。時間と遅延の両方が指定されている場合は、時間が優先されます (ただし、通常、スケジュールされた便に対して時間が指定されている場合は、GTFS のスケジュールされた時間 + 遅延に等しくするするべきである)。
+* 予測されたスケジュールがあるかどうかにかかわらず、時間を与えられ、新規または交換旅行のために与えられる必要があります。時間と遅延の両方が指定されている場合、時間が優先されます（通常、時間は、予定されている旅行に与えられた場合、GTFS +遅延のスケジュールされた時間に等しくなければなりません）。
+* 旅行が新しい、交換または重複した旅行である場合、スケジュールされた時間が与えられる場合があります。
不確実性は、時間と遅延の両方に等しく適用されます。不確実性は、実際の遅延の予想される誤差を大まかに指定します (ただし、その正確な統計的意味はまだ定義されていません)。たとえば、コンピューターのタイミング制御下で運転される列車の場合、不確実性が 0 になることがあります。
@@ -185,25 +188,28 @@ ScheduleRelationship の値に応じて、TripUpdate では以下を指定でき
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|------------|----------------|-------------------|-------------------|
-|**delay**| [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | 遅延 (秒単位) は正 (車両が遅れていることを意味する) または負 (車両がスケジュールより進んでいることを意味する) になります。遅延が 0 の場合、車両は正確に時間通りです。StopTimeEvent 内では遅延または時間のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません。 |
-|**time**| [int64](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | 絶対時間としてのイベント。 POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数) StopTimeEvent内では、遅延または時間のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません。 |
-|**uncertainty**| [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 不確実性が省略されている場合は、不明と解釈されます。完全に確実な予測を指定するには、不確実性を 0 に設定します。 |
+|**delay**| [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 つ |遅延（秒単位）は、正（車両が遅れていることを意味する）または負（車両が予定より進んでいることを意味する）の値になります。遅延が0の場合、車両は正確に時間通りに到着していることを意味します。
StopTimeUpdate.schedule_relationship が NO_DATA の場合、**禁止**です。
**必須**時刻が指定されていない場合は必須です。|
+|**time**| [int64](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 | 推定または実際のイベントの絶対時刻。POSIX時間（1970年1月1日 00:00:00 UTCからの秒数）で表されます。
StopTimeUpdate.schedule_relationship が NO_DATA の場合、**禁止**です。
**必須**遅延が指定されていない場合は必須です。|
+|**scheduled_time**| [int64](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで禁止| 1 | スケジュールされた時刻。POSIX時間（1970年1月1日 00:00:00 UTCからの秒数）で表されます。
**任意**TripUpdateが `NEW`、`REPLACEMENT`、または`DUPLICATED` の場合、**省略可能**。それ以外の場合は**禁止**。|
+|**uncertainty**| [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 不確実性が省略された場合は、不明と解釈されます。完全に確実な予測を指定するには、不確実性を0に設定してください。
StopTimeUpdateが NO_DATA の場合は**禁止**です。|
### _message_ StopTimeUpdate
便中の特定の停留所の到着イベントや出発イベントのリアルタイム更新。[TripDescriptor](#message-tripdescriptor) および [便更新エンティティ](../../../documentation/realtime/feed-entities/trip-updates) ドキュメントの停車時間更新に関する一般的な説明も参照してください。
-過去と未来の両方のイベントの更新を提供できます。プロデューサーは過去のイベントを削除できますが、必須ではありません。
+更新は、過去のイベントと将来のイベントの両方に対して提供できます。プロデューサーは、` TripUpdate`が `NEW` または `REPLACEMENT` である場合を除き、過去のイベントを削除できますが、必須ではありません。この場合、過去の停留所は車両が走行する旅程を定義するため、旅程全体が完了するまで削除してはしてはいけない。
更新はstop_sequenceまたは stop_id のいずれかを介して特定の停留所にリンクされるため、これらのフィールドのいずれかが必ず設定されているしなければならないます。1つの旅程で同じ stop_id を複数回訪れる場合は、その旅程のその stop_id のすべての StopTimeUpdates でstop_sequence を指定するするべきである。
+新しい旅程または代替の便では、GTFS 静的データ内の既存の旅程を参照せずに、旅程で訪問する停留所を指定するために更新が使用されます。このような便では、 `stop_id`、 `stop_sequence`、 `departure` 、 `arrival`をすべて設定するしなければならない。
+
**フィールド**
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|------------|----------------|-------------------|-------------------|
-|**stop_sequence**| [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | 対応する GTFS フィードのstop_times.txtと同じであるしなければならない。 StopTimeUpdate内ではstop_sequenceまたは stop_id のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません`StopTimeProperties.assigned_stop_id`は、予測の対象となる停留所を区別するために、同じ stop_id を複数回訪れる便(ループなど) で必須です。`StopTimeProperties.assigned_stop_id` が設定されている場合は、`stop_sequence`も設定するしなければならない。|
-|**stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | 対応する GTFS フィードのstops.txtと同じである必要がしなければならない。StopTimeUpdate 内ではstop_sequenceまたは stop_id のいずれ`StopTimeProperties.assigned_stop_id`を指定するしなければならない。両方のフィールドを空にすることはできません。`StopTimeProperties.assigned_stop_id` が設定StopTimeUpdateれている場合は、`stop_id` を省略して`stop_sequence`のみを使用することをお勧めします。 `StopTimeProperties.assigned_stop_id`と`stop_id`が設定されている場合、`stop_id` は`assigned_stop_id`と一致するしなければならない。 |
-|**arrival**| [StopTimeEvent](#message-stoptimeevent) |条件付きで必須| 1つ | schedule_relationship が空または SCHEDULED の場合、 StopTimeUpdate内で arrive または destination のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません。schedule_relationship が SKIPPED の場合、arrival と destination の両方を空にすることができしてもよい。schedule_relationship が NO_DATA の場合、arrival と destination の両方を空にするしなければならない。 |
-|**departure**| [StopTimeEvent](#message-stoptimeevent) |条件付きで必須| 1つ | schedule_relationship が空または SCHEDULED の場合、 StopTimeUpdate内で arrive または destination のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません。schedule_relationship が SKIPPED の場合、arrival と destination の両方を空にするしてもよい。 schedule_relationship が NO_DATA の場合、到着と出発は空でなければしなければならない。|
+|**stop_sequence**| [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | 対応する GTFS フィードのstop_times.txtと同じであるしなければならないStopTimeUpdateではstop_sequenceまたは stop_id のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません。stop_sequenceは、同じ stop_id を複数回訪れる便（ループなど）で、予測の対象となる停留所を明確にするために必須です。`StopTimeProperties.assigned_stop_id` が設定されている場合は、 `stop_sequence``StopTimeProperties.assigned_stop_id`設定するしなければならない。**必須**`TripUpdate.schedule_relationship` が `NEW` または `REPLACEMENT` の場合、値は旅程に沿って増加するしなければならない。|
+|**stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 つ | 対応する GTFS フィードのstops.txtと同じであるしなければならない。StopTimeUpdate ではstop_sequenceまたは stop_id のいずれかを指定するしなければならない。両方のフィールドを空にすることはできませんStopTimeUpdateが設定されている場合は、 `stop_id`を省略して`stop_sequence`のみを使用する`StopTimeProperties.assigned_stop_id`をお勧めします。`StopTimeProperties.assigned_stop_id` と`stop_id`が設定されている場合、 `stop_id` は`assigned_stop_id`と一致するしなければならない。**必須**`TripUpdate.schedule_relationship` が `NEW` または `REPLACEMENT` の場合。 |
+|**arrival**| [StopTimeEvent](#message-stoptimeevent) |条件付きで必須| 1 | Schedule_relationship が空または SCHEDULED の場合、 StopTimeUpdate内で arrived または departure のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません。schedule_relationship が SKIPPED の場合、arrival と departure の両方を空にするしてもよい。**必須**`TripUpdate.schedule_relationship` が `NEW` または `REPLACEMENT` の場合。 |
+|**departure**| [StopTimeEvent](#message-stoptimeevent) |条件付きで必須| 1 | Schedule_relationship が空または SCHEDULED の場合、 StopTimeUpdate内で arrived または departure のいずれかを指定するしなければならない。両方のフィールドを空にすることはできません。schedule_relationship が SKIPPED の場合、arrival と departure の両方を空にするしてもよい。**必須**`TripUpdate.schedule_relationship` が `NEW` または `REPLACEMEN`T` の場合。|
|**departure_occupancy_status**| [OccupancyStatus](#enum-occupancystatus) |任意| 1つ | 指定された停留所から出発した直後の車両の乗客の占有状況の予測。指定されている場合は、 stop_sequence を指定するしなければならない。リアルタイムの到着または出発の予測を提供せずに、departure_occupancy_status を提供するには、このフィールドに値を入力し、 StopTimeUpdate.schedule_relationship = NO_DATA を設定します。
**注意:** このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
|**schedule_relationship**| [ScheduleRelationship](#enum-schedulerelationship) |任意| 1つ | デフォルトの関係は SCHEDULED です。|
|**stop_time_properties**| [StopTimeProperties](#message-stoptimeproperties) |任意| 1つ | GTFS stop_times.txt内で定義されている特定のプロパティのリアルタイム更新
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 |
@@ -218,7 +224,7 @@ ScheduleRelationship の値に応じて、TripUpdate では以下を指定でき
|-------------|---------------|
|**SCHEDULED**| 車両は、必ずしもスケジュールの時刻に従っているわけではありませんが、静的な停留所等スケジュールに従って進んでいます。これが**デフォルト**の動作です。到着と出発の少なくとも1つを指定するしなければならない。頻度ベースの便(exact_times = 0 の GTFS frequencies.txt) には SCHEDULED 値を指定するべきではない、代わりに UNSCHEDULED を使用するするべきである。 |
|**SKIPPED**| 停留所はスキップされます。つまり、車両はこの停留所には停車しません。到着と出発は任意です。設定されている場合、`SKIPPED` は同じルート内の後続の停留所等には伝播されません (つまり、車両はルート内の後続の停留所等にも停止しますが、それらの停留所等にも`schedule_relationship: SKIPPED`の`stop_time_update`がある場合には除きます)。ルート内の前の停留所からの遅延は ` `SKIPPED`停留所にも伝播します。つまり、`SKIPPED`停留所後の停留所に対して`arrival`または`departure`予測を含む`stop_time_update`が設定されていない場合、`SKIPPED`停留所の上流の予測は、後続の停留所の`stop_time_update`が提供されるまで、ルート内の ` `SKIPPED`停留所後の停留所と後続の停留所等地に伝播します。|
-|**NO_DATA**| この停留所にはデータがありません。リアルタイムのタイミング情報がないことを示します。設定すると、NO_DATA は後続の停留所等にも伝播されるため、リアルタイムのタイミング情報がない停留所を指定するには、この方法を推奨するべきではない。NO_DATA が設定されている場合は、到着も出発も指定しないでするべきである。|
+|**NO_DATA**| この停留所にはリアルタイム データがありません。これは、リアルタイムのタイミング情報が利用できないことを示します。設定されている場合、NO_DATA は後続の停留所にも伝播されるため、リアルタイムのタイミング情報がない停留所を指定するには、この方法を使用することを推奨。NO_DATA が設定されている場合は、` TripDescriptor.schedule_relationship` が `NEW` または `REPLACEMENT` でない限り、到着または出発を指定してはいけない。その場合は、予測ではなく、スケジュールされた時刻のみを指定するしなければならない。 `TripDescriptorが `NEW` または `REPLACEMENT` の場合でも、 StopTimeUpdate が旅程の停留所リストを定義するため、 `arrival`と`departure`にはスケジュール時刻を指定するしなければならない。この場合、スケジュールは静的な GTFS とは無関係ですが、リアルタイム予測はまだ利用できないことを示しています。|
|**UNSCHEDULED**| 車両は、頻度ベースの旅程 (GTFS frequencies.txtで exact_times = 0) を運行しています。この値は、GTFS frequencies.txtで定義されていない便、または GTFS frequencies.txtで exact_times = 1.の便には使用しないでください。`schedule_relationship : `schedule_relationship: UNSCHEDULED`の`stop_time_updates`を含む便では、 TripDescriptor `schedule_relationship: UNSCHEDULED`も設定するしなければならない。
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。
### _message_ StopTimeProperties
@@ -231,6 +237,20 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|---------------------------|----------------|-------------------|-------------------|
|**assigned_stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | リアルタイムの停留所割り当てをサポートします。GTFS `stops.txt`で定義されている`stop_id`を参照します。
新しい`assigned_stop_id`によって、エンドユーザーの乗車体験が GTFS `stop_times.txt`で定義された`stop_id`と大幅に異なることはするべきではない。言い換えれば、新しい停留所が追加のコンテキストなしでアプリ内に表示された場合は、エンドユーザーがこの新しい`stop_id` を`異常な変更`と見なすべきではするべきではないん。たとえば、このフィールドは、GTFS `stop_times.txt`で元々定義された停留所と同じ駅に属する`stop_id` を使用してプラットフォームの割り当てに使用することを目的としています。
リアルタイムの到着または出発の予測を提供せずに停留所を割り当てるには、このフィールドに値を入力し、`StopTimeUpdate.schedule_relationship = NO_DATA`を設定します。
このフィールドに値を入力する場合は、`StopTimeUpdate.stop_sequence`を入力するしなければならないが、`StopTimeUpdate.stop_id` は入力するべきではない。停留所の割り当ては、他の GTFS リアルタイム フィールドにも反映されるするべきである(例: `VehiclePosition.stop_id`)。
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 |
+|**stop_headsign**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 停留所における車両の更新された行先表示。
**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
+|**drop_off_type**| [DropOffPickupType](#enum-dropoffpickuptype) |任意| 1つ | 停留所における車両の降車場所の更新値。
**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
+|**pickup_type**| [DropOffPickupType](#enum-dropoffpickuptype) |任意| 1つ | 停留所での車両の最新のピックアップ。
**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来、正式に採用されるしてもよい。 |
+
+## _enum_ DropOffPickupType
+
+**Values**
+
+| _**Value**_ | _**Comment**_ |
+|----------------------------|--------------------------------------------------------|
+|**REGULAR**| 定期的にスケジュールされた集荷/降車。 |
+|**NONE**| 集荷/降車はありません。 |
+|**PHONE_AGENCY**| 集荷/降車を手配するには、事業者に電話するしなければならない。 |
+|**COORDINATE_WITH_DRIVER**| 集荷/降車を手配するには、ドライバーと調整するしなければならない。 |
### _message_ TripProperties
@@ -245,7 +265,9 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア
|**trip_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 | (CSV) GTFS trips.txtで定義されている既存の便の複製であるが、異なるサービスdateおよび/または時刻 ( `TripProperties.start_date`および`TripProperties.start_time`を使用して定義) に開始する新しい便の識別子を定義します。(CSV) GTFS の`trips.trip_id`の定義を参照してください。その値は、(CSV) GTFS で使用されている値と異なる必要がしなければならない。このフィールドは、`schedule_relationship`が`DUPLICATED`の場合に必須です。それ以外の場合、このフィールドに値を入力することはしてはいけない、コンシューマーによって無視されます。
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 |
|**start_date**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | 複製された便が実行されるサービスdate。YYYYMMDD 形式で提供するしなければならない。このフィールドは、`schedule_relationship`が`DUPLICATED`の場合に必須です。それ以外の場合は、このフィールドに値を入力してはしてはいけない、コンシューマーによって無視されます。
**注意:** このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 |
|**start_time**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 | 重複している便の出発開始時刻を定義します。(CSV) GTFS の`stop_times.departure_time`の定義を参照してください。重複した便の予定到着時刻と出発時刻は、元の便の`departure_time`とこのフィールドのオフセットに基づいて計算されます。たとえば、GTFS の旅程に停留所 A の`departure_time`が`10:00:00` 、停留所 B の`departure_time`が`10:01:00`で、このフィールドに`10:30:00`の値が入力されている場合、複製された旅程の停留所 B のスケジュールされた`departure_time`は`10:31:00`になります。リアルタイム予測の`delay`値は、この計算されたスケジュール時間に適用され、予測時間を決定します。たとえば、停留所 B の出発`delay`が`30`の場合、予測される出発時刻は`10:31:30`です。リアルタイム予測の`time`値にはオフセットが適用されず、提供された予測時間を示します。たとえば、停留所 B の出発`time`が` 10:31:30 と指定されている場合、予測出発時刻は`10:31:30` になります。このフィールドは、`schedule_relationship`が`DUPLICATED`の場合に必須。それ以外の場合、このフィールドに値を入力するしてはいけない、消費者によって無視されます。
**注意:** このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 |
-|**shape_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | この旅程の車両移動経路の形状が元のものと異なる場合に、その形状を指定します。(CSV) GTFS で定義された形状、またはリアルタイム フィードの新しい形状エンティティを参照します。(CSV) GTFS の`trips.shape_id`の定義をご覧ください。
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
+|**trip_headsign**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | この旅行の行先表示が元のものと異なる場合に、それを指定します。
**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
+|**trip_short_name**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | この旅行の名前が元の旅行と異なる場合に指定します。
**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
+|**shape_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 旅行の形状が (CSV) GTFS で指定された形状と異なる場合、または乗客の需要に基づいて異なる経路を取る車両など、(CSV) GTFS で提供されていない場合にリアルタイムで指定する場合に、車両の旅行経路の形状の識別子を指定します。(CSV) GTFS の`trips.shape_id`の定義をご覧ください。
シェイプが（CSV）GTFSでもリアルタイムでも定義されていない場合、そのシェイプは不明とみなされます。このフィールドは、（CSV）GTFSのshapes.txtで定義されたシェイプ、または同じ（protobuf）リアルタイムフィード内の`Shape`を参照できます。この旅程の停留所順序（停車シーケンス）は、（CSV）GTFSと同じであるしなければならない。同じリアルタイムフィード内の`Shape`エンティティを参照する場合、このフィールドの値は、エンティティ内の`shape_id`の1つであり、 `FeedEntity`の`id`ではするべきであるん。
迂回が発生した場合など、元の旅行の一部であったが、今後は行わない停留所は、schedule_relationship=SKIPPED としてマークするか、 `TripModifications`messageを介して詳細を提供するするべきである。
**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
### _message_ VehiclePosition
@@ -439,7 +461,7 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア
### _message_ TripDescriptor
-GTFS 便の単一のインスタンスを識別する記述子。
+GTFS 旅行の単一のインスタンスを識別する記述子`schedule_relationship`が `NEW` の場合は、追加する旅行の新しいインスタンスを指定します。
単一の便インスタンスを指定するには、多くの場合、`trip_id`だけで十分です。ただし、次の場合には、単一の便インスタンスを解決するために追加の情報が必要です:
@@ -453,12 +475,14 @@ GTFS 便の単一のインスタンスを識別する記述子。
trip_idが不明な場合は、 TripUpdateの駅シーケンス ID では不十分であり、stop_id も提供するしなければならない。さらに、絶対的な到着/出発時刻も提供するしなければならないTripDescriptor.route_id は、ルートのすべての便に影響するルート全体のアラートを指定する Alert EntitySelector内では使用できません。代わりにEntitySelector.route_idを使用してください。
+`schedule_relationship`が `NEW` の場合は、旅行をルートに関連付けるために、 `trip_id` をしなければならないフィードにリストされていない値に設定し、 `route_id`を` GTFS スタティックの`routes.txt`にリストされている値に設定するしなければならない。新しい旅程には`start_date`を設定するするべきである、 `direction_id`を設定してもよい。
+
**フィールド**
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|------------|----------------|-------------------|-------------------|
-|**trip_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | このセレクタが参照する GTFS フィードのtrip_id 。非定期運行の便(GTFS frequencies.txtで定義されていない便) の場合、このフィールドだけで旅程を一意に識別できます。GTFS frequencies.txtで定義されている定期運行の便の場合、 trip_id、start_time、start_date はすべて必須です。スケジュールベースの便（GTFS frequencies.txtで定義されていない便）の場合、 trip_idを省略できるのは、 route_id、 direction_id 、 start_time 、 start_date の組み合わせによって旅程を一意に識別でき、それらのフィールドがすべて指定されている場合のみです。 schedule_relationship がTripUpdate内で DUPLICATED の場合、 trip_id は複製される静的 GTFS からの旅程を識別します。 schedule_relationship がVehiclePosition内で DUPLICATED の場合、 trip_id は複製される新しい旅程を識別し、対応するTripUpdateの値を含めるしなければならない。 TripProperties。 trip_id。 |
-|**route_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | このセレクタが参照する GTFS からのroute_id 。 trip_idを省略した場合、ルートインスタンスを識別するために、 route_id、 direction_id 、 start_time 、および schedule_relationship=SCHEDULED をすべて設定するしなければならない。ルートのすべての便に影響するルート全体のアラートを指定するために、 Alert EntitySelector内でTripDescriptor.route_idを使用しするべきではない。代わりにEntitySelector.route_id を使用してください。 |
+|**trip_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 | このセレクタが参照する GTFS フィードからのtrip_id 。運行頻度に基づいていない便（GTFS frequencies.txtで定義されていない便）の場合、このフィールドだけで旅程を一意に識別できます。GTFS frequencies.txtで定義されている運行頻度に基づく便の場合、 trip_id、start_time、start_date はすべて必須です。スケジュールベースの便（GTFS frequencies.txtで定義されていない便）の場合、 trip_idを省略できるのは、 route_id、 direction_id 、 start_time 、 start_date の組み合わせで旅程を一意に識別でき、かつそれらのフィールドがすべて指定されている場合のみです。schedule_relationship が NEW の場合は、 GTFS 静的に定義されていない一意の値で指定するしなければならない。schedule_relationship が `REPLACEMENT` の場合、 trip_id は置換される静的 GTFS からの旅程を識別します。 TripUpdate内で schedule_relationship が`DUPLICATED`の場合、 trip_id は複製される静的 GTFS からの旅程を識別します。 VehiclePosition内で schedule_relationship が`DUPLICATED`の場合、 trip_id は複製される新しい旅程をしなければならないし、対応するTripUpdate. TripProperties.trip_id. |
+|**route_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | このセレクタが参照する GTFS のroute_idを省略した場合、 trip_id 、 route_id、 start_time 、および schedule_relationship=SCHEDULED をすべて設定して、旅程インスタンスを識別するしなければならない。 Alert EntitySelector内で、ルートのすべての便に影響するルート全体のアラートを指定するためにTripDescriptor.route_idを使用しするべきではない。代わりにEntitySelector.route_id を使用してください。schedule_relationship が NEW の場合、新しい旅程が属するルートのroute_idを指定するしなければならない。|
|**direction_id**| [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | GTFS フィードのtrips.txtファイルの direction_id。このセレクタが参照する便の移動方向を示しますtrip_idを省略した場合、 direction_id を指定するしなければならない。
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。
|
|**start_time**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 | この旅程インスタンスの当初の予定開始時刻。trip_idが非頻度ベースの旅程に対応する場合、このフィールドは省略するか、GTFS フィードの値と同じにするするべきである。trip_idがGTFS frequencies.txtで定義された頻度ベースの旅程に対応する場合、start_time は必須であり、旅程の更新と車両の位置のために指定するしなければならない。旅程が exact_times=1 の GTFS レコードに対応する場合、start_time は対応する期間のfrequencies.txt のstart_time より headway_secs の倍数 (0 を含む) 後にするしなければならない。旅程が exact_times=0 に対応する場合、start_time は任意でかまいませしてもよいが、当初は旅程の最初の出発時刻になると予想されます。一度設定されると、この頻度ベースの exact_times=0 の旅程の start_time は、最初の出発時刻が変更された場合でも不変と見なすするべきである。その時間変更は、代わりにStopTimeUpdateに反映されるしてもよいtrip_idを省略する場合は、 start_time を指定するしなければならない。フィールドの形式とセマンティクスは、GTFS/frequencies.txt/start_time と同じです (例: 11:15:35 または 25:15:35)。|
|**start_date**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1つ | この旅程インスタンスの開始date(YYYYMMDD 形式)。スケジュールされた便(GTFS frequencies.txtで定義されていない便) の場合、翌日のスケジュールされた旅程と重なるほど遅れている便を明確にするために、このフィールドを指定するしなければならない。たとえば、毎日 8:00 と 20:00 に出発し、12 時間遅れている列車の場合、同じ時間に 2つの異なる便が存在することになります。このフィールドは指定できますが、このような衝突が不可能なスケジュールでは必須ではありません。たとえば、1 時間遅れている車両はスケジュールとは関係がないと見なされる、1 時間ごとのスケジュールで実行されるサービスなどです。このフィールドは、GTFS frequencies.txtで定義されている頻度ベースの便では必須。trip_idが省略されている場合は、start_date を指定するしなければならない。|
@@ -467,17 +491,19 @@ trip_idが不明な場合は、 TripUpdateの駅シーケンス ID では不十
### _enum_ ScheduleRelationship
-この便と静的スケジュールの関係。旅程が GTFS に反映されていない臨時スケジュールに従って行われる場合、SCHEDULED ではなく ADDED としてマークする必要があります。
+この旅程と静的スケジュールの関係。新しい旅程が GTFS に反映されない一時的なスケジュールに従って行われる場合、その旅程は SCHEDULED ではなく NEW としてマークする必要があります。旅程が GTFS に反映されていない変更されたスケジュールに従って行われる場合、その旅程は`SCHEDULED`ではなく `REPLACEMENT` としてマークする必要があります。
**値**
| _**値**_ | _**コメント**_ |
|-------------|---------------|
| **SCHEDULED** | GTFS スケジュールに従って運行されている、またはスケジュールされた運行に十分近いため関連付けられている運行。 |
-| **ADDED** | 故障した車両を交換するため、または突然の乗客の増加に対応するためなど、運行スケジュールに加えて追加された運行。 *注: 現在、このモードを使用するフィードの動作は指定されていません。GTFS GitHub [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221) [(3)](https://github.com/google/transit/pull/219) では、ADDED 運行を完全に指定するか廃止するかについて議論されており、その議論が確定次第、ドキュメントが更新されます。* |
+| **ADDED** | *注: この値は動作が指定されていないため非推奨になりました。開始dateを除いてスケジュール済みの旅程と同じ追加の旅程の場合は**DUPLICATED**を使用し、既存の旅程とは無関係な追加の旅程の場合は**NEW**を使用してください。* |
| **UNSCHEDULED** | スケジュールが関連付けられていない運行中の旅程 - この値は、GTFS frequencies.txt で exact_times = 0 に定義されている旅程を識別するために使用されます。GTFS frequencies.txt で定義されていない旅程や、GTFS frequencies.txt で exact_times = 1 に定義されている旅程を説明するために使用しないでください。`schedule_relationship: UNSCHEDULED` の旅程では、すべての StopTimeUpdates も `schedule_relationship: UNSCHEDULED` に設定する必要があります。|
| **CANCELED** | スケジュールに存在していたが削除された旅程。|
+|**REPLACEMENT**| 変更されたスケジュールや迂回ルートなどにより、既存のスケジュール済みの旅程を置き換える旅程。代替旅行の完全な行程は`StopTimeUpdate`で指定するしなければならない、GTFS 静的からの元のスケジュールは、置き換えられたインスタンスには使用されません。
`REPLACEMENT` は、旅行が修正されたスケジュールで運行されている場合に使用できますが、車両が静的 GTFS の`stop_times.txt`にリストされているスケジュールに従うことを目的としている場合は、リアルタイムのスケジュールの逸脱 (予測) を伝えるために使用するしてはいけない。
**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
| **DUPLICATED** | サービス開始日時を除き、既存のスケジュールされた旅程と同じ新しい旅程。 `TripUpdate.TripProperties.trip_id`、`TripUpdate.TripProperties.start_date`、および `TripUpdate.TripProperties.start_time` と一緒に使用して、静的 GTFS から既存の旅程をコピーしますが、開始日は異なるサービス日付および/または時刻にします。(CSV) GTFS (`calendar.txt` または `calendar_dates.txt`) 内の元の旅程に関連するサービスが今後 30 日以内に運行される場合、旅程の複製が許可されます。複製する旅程は、`TripUpdate.TripDescriptor.trip_id` によって識別されます。
この列挙では、`TripUpdate.TripDescriptor.trip_id` によって参照される既存の旅程は変更されません。プロデューサーが元の旅程をキャンセルする場合は、CANCELED の値を持つ別の `TripUpdate` を公開する必要があります。 GTFS の `frequencies.txt` で定義されている、`exact_times` が空または `0` に等しい旅程は複製できません。新しい旅程の `VehiclePosition.TripDescriptor.trip_id` には、`TripUpdate.TripProperties.trip_id` の一致する値が含まれている必要があり、`VehiclePosition.TripDescriptor.ScheduleRelationship` も `DUPLICATED` に設定する必要があります。
*重複した旅程を表すために ADDED 列挙を使用していた既存のプロデューサーとコンシューマーは、[移行ガイド](../../realtime/examples//migration-duplicated) に従って DUPLICATED 列挙に移行する必要があります。* |
+|**NEW**| 既存の便とは無関係な追加の旅程。例えば、急激な乗客増加に対応するために使用します。新しい旅程の全行程（停留所と時刻を含む）は、 `StopTimeUpdate`で指定するしなければならない。
*静的 GTFS に関連しない新しい便を表すために`ADDED`列挙を使用していた既存のプロデューサーとコンシューマーは、[移行ガイド](/gtfs-realtime/spec/en/examples/migration-duplicated.md) に従って NEW 列挙に移行するしなければならない。*
**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
| **DELETED** | スケジュールに存在していたが削除された旅程で、ユーザーに表示してはいけません。
交通事業者プロバイダーが、対応する便に関する情報を消費アプリケーションから完全に削除し、乗客に便がキャンセルされたと表示されないようにするには、CANCELED ではなく DELETED を使用する必要があります。たとえば、便が別の便に完全に置き換えられる場合などです。この指定は、複数の便がキャンセルされ、代替サービスに置き換えられる場合に特に重要になります。消費者がキャンセルに関する明確な情報を表示すると、より重要なリアルタイム予測が妨げられます。
**注意:** このフィールドはまだ **実験的** であり、変更される可能性があります。将来正式に採用される可能性があります。|
## _message_ ModifiedTripSelector
@@ -588,7 +614,7 @@ Textのスニペットまたは URL の言語別バージョンを含む国際
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|------------|----------------|-------------------|-------------------|
|**shape_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ | 形状の識別子。(CSV) GTFS で定義されている`shape_id`とは異なる必要がしなければならない。
**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 |
-|**encoded_polyline**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ | 形状のエンコードされたポリライン表現。このポリラインには少なくとも 2つのポイントが含まれているしなければならない。エンコードされたポリラインの詳細については、https://developers.google.com/maps/documentation/utilities/polylinealgorithm をご覧ください。
**注意:** このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。|
+|**encoded_polyline**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ | 形状のエンコードされたポリライン表現。このポリラインは少なくとも2つのポイントを含み、使用されるルートの完全な形状を表すしなければならない。エンコードされたポリラインの詳細については、https://developers.google.com/maps/documentation/utilities/polylinealgorithm をご覧ください。
**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 |
### _message_ Stop
@@ -601,7 +627,7 @@ Textのスニペットまたは URL の言語別バージョンを含む国際
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|------------|----------------|-------------------|-------------------|
|**stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ | 停留所の識別子。(CSV) GTFS で定義されている`stop_id`と異なる必要がしなければならない。|
-|**stop_code**| [TranslatedString](#message-translatedstring) |任意| 1つ | (CSV) GTFS の [停留所等.stop_code](https:](https: ) の定義を参照してください。|
+|**stop_code**| [TranslatedString](#message-translatedstring) |任意| 1つ | (CSV) GTFS の [停留所等.stop_code](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。|
|**stop_name**| [TranslatedString](#message-translatedstring) |必須| 1つ | (CSV) GTFS の [停留所等 .stop_name](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。|
|**tts_stop_name**| [TranslatedString](#message-translatedstring) |任意| 1つ | (CSV) GTFS の [停留所等.tts_stop_name](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。|
|**stop_desc**| [TranslatedString](#message-translatedstring) |任意| 1つ | (CSV) GTFS の [停留所等.stop_desc](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。|
@@ -690,8 +716,8 @@ Textのスニペットまたは URL の言語別バージョンを含む国際
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|------------|----------------|-------------------|-------------------|
-|**trip_ids**| [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | 多数 | 1つ | 元の (CSV) GTFS のtrip_idのリストで、含まれている置換によって影響を受けます。少なくとも 1つのtrip_idを含める必要があります。|
-|**shape_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ |このSelectedTripsで変更された便の新しい形状のID-RT Shapemessageを使用して追加された新しい形状、または GTFS-Static フィードのshapes.txtで定義されている既存の形状を参照するしてもよいます。|
+|**trip_ids**| [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | 多数 | 1 | 包含する置換によって影響を受ける元の（CSV）GTFS のtrip_idのリスト。少なくとも 1 つのtrip_idを含める必要があります。`schedule_relationship=REPLACEMENT` が指定された`TripUpdate`が、この旅行にまだ存在してはしてはいけない。 |
+|**shape_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 | このSelectedTrips内の変更された便の新しいシェイプのID 。同じ GTFS-RT フィード内の`Shape`messageを使用して追加された新しいシェイプ、または GTFS-Static フィードのshapes.txtで定義されている既存のシェイプを参照する場合がしてもよい。リアルタイム フィード内の`Shape`エンティティを参照する場合、このフィールドの値はエンティティ内の`shape_id`のいずれかであり、 `FeedEntity`の`id`ではありするべきであるん。|
### _message_ ReplacementStop
@@ -707,5 +733,5 @@ Modificationが旅程の最初の停留所に影響する場合、その停留
| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ |
|------------------|------------|----------------|-------------------|-------------------|
-|**stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ | 旅程で今後訪問される代替の停留所ID-RT の`Stop`messageを使用して追加された新しい停留所、または (CSV) GTFS フィードの``stops.txt``で定義されている既存の停留所をしてもよいする場合があります。停留所には``location_type=0`` (ルート可能な停留所等) がしなければならない。|
+|**stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | 旅程で今後訪問される代替の停留所ID 。同じGTFS-RTフィード内のGTFS-RT `Stop`messageを使用して追加された新しい停留所、または（CSV）GTFSフィードの`stops.txt`で定義されている既存の停留所を参照する場合がしてもよい。リアルタイムフィード内の`Shape`エンティティを参照する場合、このフィールドの値はエンティティ内の`stop_id`のいずれかでするべきである、 `FeedEntity`の`id`ではありません。停留所は`location_type=0` （ルート可能な停留所）であるしなければならない。|
|**travel_time_to_stop**| [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | この停留所への到着時間と参照停留所への到着時間の差 (秒単位)。参照停留所は、`start_stop_selector` の前の停留所です。Modificationが便の最初の停留所で開始される場合、便の最初の停留所が参照停留所になります。
この値は単調に増加するしなければならないがあり、元の便の最初の停留所が参照停留所である場合にのみ負の数になるしてもよい。
値が指定されていない場合、消費者は他のデータに基づいて `travel_time_to_stop` を補間または推測するしてもよい。|