Open
Description
Describe the problem
The GTFS-RT specification for StopTimeEvent specifies that:
Timing information for a single predicted event (either arrival or departure). Timing consists of delay and/or estimated time, and uncertainty.
delayshould be used when the prediction is given relative to some existing schedule in GTFS.timeshould 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).
However, for an ADDED or DUPLICATED trip, there is currently no means to specify the scheduled time of the added or duplicate trip (for example, if the duplicated trip is scheduled to run slower than the original).
Use cases
- A train company wants to add a new, ad hoc trip, not on any existing trip patterns, which adheres to a schedule, for example, an event special.
- A bus company wants to run a duplicate service timed 5 minutes before the original, but because of the slower boarding / alighting speed of the relief vehicle, it is planned to run slower than the original and eventually arrives the destination at the same time as the original.
Proposed solution
Change the definition of the message StopTimeEvent in GTFS-RT to be:
Timing information for a single predicted event (either arrival or departure). Timing consists of delay and/or estimated time, and uncertainty.
- 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
** For scheduled trips, time will take precedence (although normally, time, if given for a scheduled trip, should be equal to scheduled time in GTFS + delay).
** For added and duplicated trips, if a delay is also specified, it represents the actual time for the new trip for which the scheduled time can be calculated - 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.
| Field Name | Type | Required | Cardinality | Description |
|---|---|---|---|---|
| delay | int32 | 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. If TripDescriptor.schedule_relationship is SCHEDULED, the delay is measured against the GTFS static schedule.If TripDescriptor.schedule_relationship is either ADDED or DUPLICATED, the delay is included in the actual time below, which must be provided. If TripDescriptor.schedule_relationship is UNSCHEDULED, this field must be empty.Either delay or time must be provided within a StopTimeEvent - both fields cannot be empty. |
| time | int64 | Conditionally required | One | Event as absolute time. In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC). If TripDescriptor.schedule_relationship is either ADDED or DUPLICATED, and both delay and time are specified, this is the actual time where the scheduled time can be calculated by subtracting the delay. If TripDescriptor.schedule_relationship is SCHEDULED, this value overrides the time calculated by delay.Either delay or time must be provided within a StopTimeEvent - both fields cannot be empty. |
| uncertainty | int32 | Optional | One | If uncertainty is omitted, it is interpreted as unknown. To specify a completely certain prediction, set its uncertainty to 0. |
Additional information
No response