Allow specifying both the scheduled time and delay in StopTimeEvent for added and duplicated trips.

[miklcct]

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.

• 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).

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

[miklcct]

I have made an implementation for ADDED trips for OpenTripPlanner in https://github.com/Jnction/OpenTripPlanner/tree/delay_on_added_trips

OpenTripPlanner does not support DUPLICATED trips yet.

[miklcct]

I have changed the proposal for ADDED and DUPLICATED trips to use the actual time at the time field. This retains compatibility for consumers which doesn't support delay in these trips.