Trip Properties Start Date for Canceled Trips

[john-burge-sys]

In implementing GTFS-RT ServiceChange v3.1, future detours may require that future trips need to be canceled. New trips are created and given start dates for the desired detour. The original trip needs to be removed so consumers that allow for trip planning for future dates will have the correct trips and stops.

My thought was to use trip update to indicate the canceled trips. That would also require that a date is specified for the canceled trip. The logical field would be to use the TripProperties.start_date. The description indicates that this field should only be used when the schedule_relationship file is set to DUPLICATED. In that case I am without the ability to indicate when a trip is canceled for any day other than today.

Looking for recommendations.

[barbeau]

@john-burge-sys Just to clarify your question with an example - I believe you're saying that there is a trip with ID 1 defined in the static GTFS schedule (zip file) that runs for the next 30 days. You want 1 to remain active for the next 10 days, but then cancel it for days 11-30 because you know now that it will be replaced with a detour. Is that right?

Others can chime in, but I think ideally this longer-term change would be reflected in the GTFS data itself rather than the real-time feed. Would this be possible?

The TripProperties.start_date for DUPLICATED trips (which, by the way, is now an official experimental field in the spec as of #221), was restricted just to the DUPLICATED case so we didn't add another way of modifying trips - to keep it simpler for consumers with less likelihood of errors.

If you must use the real-time feed, there is an option to use an Alert with a time range and effect of NO_SERVICE:
https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/reference.md#message-timerange

There still needs to be some clarification in the spec about how NO_SERVICE should be handled by consumers (specifically that it impacts routable trips on these days, as opposed to simply being an informational message shown to users) but more consumers seem to be interpreting it this way.

[john-burge-sys]

I believe you're saying that there is a trip with ID 1 defined in the static GTFS schedule (zip file) that runs for the next 30 days. You want 1 to remain active for the next 10 days, but then cancel it for days 11-30 because you know now that it will be replaced with a detour. Is that right?

@barbeau not quite. Trip with the id of 1 is replaced with detour and the newly created trip is 100001. The desire is to then publish the new trip and indicate that the dates that this trip will be active is for today plus the next 7 days. I can cancel trip ID 1 for today. How do I indicate to a consumer that trip ID 1 will be canceled for the next 7 days?

[barbeau]

How do I indicate to a consumer that trip ID 1 will be canceled for the next 7 days?

@john-burge-sys Ok, thanks for clarifying. In that case, I believe using the Alert for trip_id 1 with a time range for the next 7 days and effect of NO_SERVICE is the best approach.

@tleboulenge @anatolip-rt @gcamp Any thoughts on this as consumers?

[skinkie]

@barbeau I don't think Alerts should effect routing.

[stevenmwhite]

@barbeau I don't think Alerts should effect routing.

Why not? Alerts include stop closures, temporary no service on routes, and detours... those are all things that should affect routing, as a trip planner wouldn't want to tell riders to use a stop or route that is not in service.

As a feed producer, we definitely expect that consumers will take our alerts feed into account when directing riders.

[skinkie]

@stevenmwhite because from a modelling perspective it is a informal message to be presented to the user, unlike for example tripUpdates. https://developers.google.com/transit/gtfs-realtime/guides/service-alerts

Service alerts allow you to provide updates whenever there is disruption on the network. Delays and cancellations of individual trips should usually be communicated using Trip updates, or Vehicle Positions, using schedule_relationship in the Trip Descriptor.

As a feed producer, we definitely expect that consumers will take our alerts feed into account when directing riders.

Sure, as an informal message that could be added after routing at the presentation phase. Depending on your use case that is good enough, but the specifications don't show that it should ignore the trip for a pareto optimal results. If that was the case your service alert would never be presented to the user in the first place. Or doing two journey plannings (expected and actual) and combine them at presentation.

[stevenmwhite]

I know it's outside of the specific example of trip cancellations presented earlier, but on the general topic of using alerts in route planning... here is an example from a feed we produce being consumed by Transit. A particular stop is closed, so the planner suggests exiting the bus a stop earlier and walking.

This is, in my opinion, a good and proper way to plan the journey... Rather than telling the user to use the stop while simultaneously giving them info that it's closed, don't tell them to use that stop at all (the alert info appears on a general screen rather than within the context of a journey). This is only possible if the planner uses the alerts feed for its planning purposes.

[stevenmwhite]

Apologies! I misinterpreted that journey plan. Transit actually does not take that alert into account and you can see that here. My previous screenshot was showing a journey plan on a different route.

That being said, I do still think it would be advantageous to a rider to take the alert effects into account for planning purposes and that was our expectation as a producer.

[skinkie]

That being said, I do still think it would be advantageous to a rider to take the alert effects into account for planning purposes and that was our expectation as a producer.

I think this is outside of the scope of this specific topic. But we basically arrive in the ball park "would you represent the actual data as new ground truth" or "your riders are smart asses and must be informed that a stop has been closed, because they will otherwise ignore your informed advise and stay in the vehicle because they expect it to stop there". A service alert might facilitate the second thing, but I rather not have the second result if the actual data could come up with a better alternative.

[barbeau]

@skinkie Just to clarify - how would you suggest expressing "trip 1 is canceled for the next 7 days" in GTFS-realtime?

[skinkie]

TripUpdate/TripDescriptor with trip_id=1, start_date=2020-09-23, ScheduleRelationship=Cancelled
TripUpdate/TripDescriptor with trip_id=1, start_date=2020-09-24, ScheduleRelationship=Cancelled
TripUpdate/TripDescriptor with trip_id=1, start_date=2020-09-25, ScheduleRelationship=Cancelled
TripUpdate/TripDescriptor with trip_id=1, start_date=2020-09-26, ScheduleRelationship=Cancelled
TripUpdate/TripDescriptor with trip_id=1, start_date=2020-09-27, ScheduleRelationship=Cancelled
TripUpdate/TripDescriptor with trip_id=1, start_date=2020-09-28, ScheduleRelationship=Cancelled
TripUpdate/TripDescriptor with trip_id=1, start_date=2020-09-29, ScheduleRelationship=Cancelled

[barbeau]

Ah, right, I believe that should work. ☝️

So I believe the best practice would be to provide both the TripUpdate with the dates for the next 7 days as CANCELED as well as an Alert with NO_SERVICE that can be shown to riders explaining the detour.

I'll open a separate issue for the "should alerts impact routing/presentation?" discussion. (EDIT - issue opened at #246)

[skinkie]

@barbeau How can we make sure that these kind of best-practices appear in the documentation at gtfs.org?

[barbeau]

@skinkie MobilityData is working on a GTFS-realtime best practices document that will be similar to https://gtfs.org/best-practices/ for static. I'll add this to the list.

Producers and consumers - please speak up if for some reason the above solution for canceling trips for the next 7 days isn't optimal for you.

[sam-hickey-arcadis]

See our comment at #246 (comment) as it relates to the discussion here as well.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[skinkie]

Keep open @barbeau ?

[barbeau]

I think this could actually be closed - we did include a new best practice in the MobilityData GTFS Realtime Best Practices for this case. From https://github.com/MobilityData/GTFS_Realtime_Best-Practices/blob/master/en/Alert.md:

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

I'll close it, but please feel free to re-open if anyone feels parts of this conversation remain unaddressed (note there is a separate issue open for "Do Alerts with NO_SERVICE effect for stop/trip/route impact itineraries shown to riders?" at #246).