Draft proposal : GTFS-TripModifications

[gcamp]

Hi everyone,

GTFS-ServiceChanges v3.1 has been in the proposal stage for a long time and spans very wide.

We want to move forward with the trip detour use case specifically. We saw the need for a more focused specification tailored to consistent and accurate representation of detours.

For these reasons, we came up with GTFS-TripModifications. Indeed, GTFS-TripModifications allow us to give more specific details and to be more efficient when a detour affects multiple trips, compared to a complete replacement of each affected trip, as is currently provided for in GTFS-ServiceChanges v3.1.

We just released today our first implementation of our detour feature that uses data formatted in this proposition. Swiftly is also already interested in producing this data.

We welcome your feedback either here, or directly in the Google doc! Note that GTFS-TripModifications builds on GTFS-ServiceChanges v3.1 and uses some parts of it. This proposal doesn’t prevent the remaining features in that specification from being adopted in the future.

[mads14]

Thanks for the proposal @gcamp and Transit!

As mentioned above, Swiftly is in support of this change! While the newShape addition to the GTFS-rt spec allows users to specify a newShape for given trips, it does not allow for new/temporary stops to be specified and does not allow for these replacement stops to have realtime predictions associated with them. This TripModifications proposal solves this problem by allowing “replacement stops” to be specified for a group of trips.

It is also my understanding that the propagated_modification_delay allows for trip-planning software to proactively schedule with the detour-aware trip travel time info, whereas, if the info was only reflected in the real-time predictions via "trip updates", the trip-planning software would not be able to use the detour-aware travel-time info.

Swiftly will be following along to see what questions and comments arise. We have already given Transit quite a bit of feedback on the proposal.

[sam-hickey-arcadis]

Thanks for this proposal! We agree better communication of detours would have many benefits, so it’s great to see interest from others as well.

One high-level impression from this proposal is that it is aimed at communicating detours and the effect of detours on predictions. Both of these are really important, but we suggest decoupling them.

We work with many agencies that would be eager to have their staff enter information about detours (close stops, add existing or temporary stops to routes, provide detour shape), but these same staff likely would not be able to always enter accurate data regarding how the detour will change vehicle travel times. Some agencies also may not want to publish adjusted travel time values (propagated_modification_delay and travel_time_to_stop) due to concerns about data quality (regardless of whether they are machine or human generated). We suggest making propagated_modification_delay and travel_time_to_stop optional fields. And even if a producer does not include them, we expect significant improvements to how detours are communicated to customers.

This proposal suggests including detours (TripModifications) in an agency’s TripUpdates feed. This would limit production of this data to systems that generate a TU feed, or if this data comes from a system that doesn’t generate an agency’s main TU feed then this additional TU feed would need to be merged with an agency’s main TU feed, either by the agency/producer or consumers. Are there reasons TripModifications need to be in the TU feed? What about putting it in alerts.pb or a new tripmodifications.pb?

A final piece of feedback is related to the following from the proposal:

All trips linked by those trip_ids MUST have the same stop pattern. Two trips have the same stop pattern, if they visit the same stops in the same order, and have identical stop sequences.

This has the potential to greatly increase the amount of data needed to communicate a single detour. For example, a detour that applies to 3 stops served by 5 routes that each have 5 stop patterns would require 25 TripModifications that all contain the same data other than the list of trip_ids. A detour on 3rd Avenue in Downtown Seattle is just one example of one detour affecting many routes and stop patterns (see map here). Is there a reason grouping trip_ids by stop pattern was chosen (perhaps to allow more fine-grained (at the stop pattern level) control of adjusted travel times?) rather than other options like defining the affected route, trip, stop, etc. as done in an alert’s informed_entity?

Looking forward to hearing what others think. It would be great to start moving forward on publishing better detour data.

[gcamp]

Thanks for the review and comment @sam-hickey-ibigroup!

One high-level impression from this proposal is that it is aimed at communicating detours and the effect of detours on predictions. [...] We suggest making propagated_modification_delay and travel_time_to_stop optional fields.

We agree! We're going to change the proposal to reflect that.

This proposal suggests including detours (TripModifications) in an agency’s TripUpdates feed.

This might have been implicit in some places, but it wasn't our goal. We're going to clarify. I would add a reminder that the convention of having different type of gtfs-rt updates in different files, but the spec doesn't require it. It's really up to the producer to define what is more convenient for them.

Is there a reason grouping trip_ids by stop pattern was chosen

This would allow us select stops with stop_sequence instead of stop_id, which might be problematic in cases where there are repeated stops. Using a range of stop_sequence also allows us to get some 'free' enforcement on the fact that stops should be continuous. Even if it's technically possible to have a more fuzzy match pattern, we feel being explicit is preferable.

[jmburge]

Thanks for the proposal. I like some of the concepts that are found here. I have a few questions about potential implementation based on work that we at Vontas has done in this area.

On any given service date, a trip MUST NOT be assigned to more than one detour.

I have seen agencies that have multiple detours on a single stop pattern. The longer the route, the higher probability that there could be multiple detours. I could be reading this incorrectly, so I would need to have a better understanding of how that would work.

The detour is in effect on all of the listed service_dates, until it is removed from the feed.

How would this work where a detour has an undetermined end date. I have seen a case where all detours are entered with no end dates. How would the consuming application handle this scenario? How should the AVL system provide this data?

If a modification affects the first stop of the trip, that stop also serves as the reference stop of the modification.

This one is minor but, what happens if the first stop is the reference point but not cancelled in the detour? Then the first stop is the reference and not modified.

I would also like to thank @sam-hickey-ibigroup for bringing up points that I feel are also very relevant to the implementation here.

What I would like to see is a way for the features presented here to be merged with the GTFS-RT v3.1 proposal and arrive at one solution that meets sharing detour information.

[gcamp]

Thanks for the review @jmburge!

I have seen agencies that have multiple detours on a single stop pattern.

Yes, in this case you would have a a single TripModifications entity (a trip MUST be assigned to a single TripModifications), and that TripModifications contains one or more Modifications. I've clarified the langage a bit on this.

How would this work where a detour has an undetermined end date.

We thought it would be reasonable to always provide an estimated end time, even if the end is actually unknown. The producers can probably know if it's short term (today) or medium term (couple days). It does indeed mean that you need to re-generate the protobuf regularly to update it, when necessary. Would that be acceptable to you?

This one is minor but, what happens if the first stop is the reference point but not cancelled in the detour?

The reference stop is only the reference to calculate travel time to added stops. Assuming a stop sequence that starts a 1 and increment by 1 every stop, you would set start_stop_sequence to 1 to cancel the first stop and start_stop_sequence to 2 to cancel the second stop.

What I would like to see is a way for the features presented here to be merged with the GTFS-RT v3.1 proposal

What would be the purpose of merging with service changes proposal? Our plan was the propose the TripModifications as-is. Our proposal is compatible with the rest of the v3.1 changes and uses part of it.

[gcamp]

This feature is ready for the PR stage, discussion can continue there!