Best way forward to describe significant rail disruptions

[colemccarren]

Hi everyone!

Baltimore's Light Rail service is MTA Maryland's last remaining transit mode without a public-facing GTFS-RT feed. Our goal is to launch a feed that, even during significant service disruptions, could populate passenger-facing trip planning applications as well as the digital signage on our train platforms. Consistent, accurate, standardized information everywhere is totally the goal here. Unfortunately, we are now under the impression that the GTFS and GTFS-RT spec today can not adequately describe two extremely common scenarios on our Light Rail service:

1. "Short turns" / "turn backs" / "end closure" scenarios: Characterized by one or more stations closed to revenue service extending out from a route terminus point where trains normally turn around to end one trip and begin another.
2. "System split" scenarios: Characterized by one or more stations closed to revenue service that are surrounded by stations that are open to revenue service. Trains are forced to short turn in two different locations where they are not normally scheduled to do so, effectively splitting one "line" in to two separate "lines" with potentially different headways (though they share the same route name).

Looking through the static and RT documentation, we hoped that we could use DUPLICATED trips that were pre-defined in the GTFS to describe different segments of our system to then pull them in to the RT feed whenever necessary. We tested out a handful of approaches, such as defining those trips as occurring "in the past" or "exactly 29 days in the future at all times". We've now come to understand that DUPLICATED really seems to be intended for additional "tripper" types of situations, and not for describing more advanced scenarios.

For what it's worth, our team likes the idea of being able to define trips part of an "on-call" service_ID within the calendar.txt where all days = 0 as a relatively simple way to define dynamic changes in a lot of different use cases (snow routes, reduced commuter services, bus bridges, rail system splits and short turns, etc.) and imagine it could also cut down on the amount of data necessary in the RT feeds. I'm not sure where the ServiceChanges proposal stands today now that DUPLICATED trips and encoded polyline DETOURs are accepted experimental features, but I imagine that describing the types of services listed above through the static GTFS could be valuable in terms of data transfer / size of RT feeds as well as simplicity for the spec? Just throwing ideas out there, of course - that's why we're asking :)

Essentially, we'd like to pose these questions to the greater community, as we'd really like to launch RT on our Light Rail service as soon as possible - but are striving to utilize GTFS to the greatest capacity available.

1. Has anyone been able to describe these types of rail disruptions (short turns, system splits) within the spec as it stands today? If so, how?
2. Does anyone have thoughts on what might be immediately next for the spec that could address these types of disruptions, and what might be further away from a production standpoint?

And of course, in general, would love to hear any producer / consumer / other agency thoughts on any/all the above. Thanks in advance!

[skinkie]

I think you should prevent mixing your AVL dispatch scenarios with technical means to communicate it. As developer I understand that users of transfer patterns based journey planners have issues with 'unseen' trip patterns. Therefore introducing scenarios a head of time might make sense for a certain user base. But what is it that you really want? It is basically introducing "new trips" or at least "stop sequences". For the two scenarios above the first one would not require new trips, and can be achieved with regular GTFS-RT. The second one is more challanging, considering that it happens on the fly, and is therefore unscheduled. In all other scenarios you could just create a schedule exactly matching the behavior. The realtime scenario only becomes difficult if you want to have auxiliary that you cannot communicate (yet) in GTFS-RT. For example you want to do a detour and give it a new shape.

From the GMaps perspective I heard that providing unscheduled trips (so no calendar service at all), and activating them in real time works.

[colemccarren]

Thanks for the response, Stefan. I'll add a point of clarification that sometimes, the first scenario can be achieved with regular GTFS-RT, but for large unplanned sections of track that get closed (downed tree, for instance) and require short turns, sometimes the headway changes on the line enough so that service frequency might actually improve. Obviously, this is a bit strange from a GTFS perspective, but it is the reality of our service when there are more trains out in revenue service than would be necessary to maintain the regularly scheduled headways across a shorter than usual distance / smaller number of stops. As a hypothetical example of what I mean: a 15-minute headway might become a 12-minute headway to avoid bunching across a shorter stretch of active track. Over the course of the day, the number of trips in the GTFS might get outnumbered by the number of trips actually performed.

It seems that GTFS-ServiceChanges could address both the scenarios (short turns AND system splits), perhaps via NewTrips + NewShapes or perhaps just ServiceUpdates, but we acknowledge that proposal hasn't moved much the last couple years.

Just for discussion's sake (since we want to fact find as much as we can!) - a couple additional questions:

1. Would the members of this community agree that ServiceChanges is necessary to model the types of short turns and system splits I have described above? Or might there be something we missed in the current spec that would work to convey these changes (beyond a service alert)?

2. Do any agencies describe these types of changes (or similar scenarios) currently within their GTFS-RT? If so, what is their/your approach? For example, if you encounter these issues now - do you shut off predictions in certain areas? Calculate predictions differently? How do you communicate with passengers using trip planning applications?

[skinkie]

1. I disagree that ServiceChanges is required. Today GTFS-RT allows everything that can be received from any AVL on the market. If there is any AVL available that honestly can create trips on the fly (as in: unscheduled trips, unseen trip patterns, unseen routes, realtime rerouting on a map) I would like to know if that producer is capable of creating ServiceChanges. In all other cases: I think we can manage a detour by just updating the stop sequences in GTFS-RT.
2. For The Netherlands we have a "special" trainUpdates.pb which is tripUpdates.pb but with all the fancy rail magic. For this a consumer much implement the under specified "ADDED" status. The main reason for splitting them from the bus transport is that when trains are cancelled over here, typically they get replaced (new trip_id etc.) So a journey planner that can cancel, but cannot 'recover' gives a suboptimal end-user experience.

[barbeau]

We've now come to understand that DUPLICATED really seems to be intended for additional "tripper" types of situations, and not for describing more advanced scenarios.

That's correct - DUPLICATED is intended for use where you're running the same sequence of stops, just at a different start_date/start_time. So a "copy/paste" of a trip to a different time.

For what it's worth, our team likes the idea of being able to define trips part of an "on-call" service_ID within the calendar.txt where all days = 0 as a relatively simple way to define dynamic changes in a lot of different use cases (snow routes, reduced commuter services, bus bridges, rail system splits and short turns, etc.) and imagine it could also cut down on the amount of data necessary in the RT feeds.

This is effectively what the proposed "GTFS-ServiceUpdates" portion of GTFS-ServiceChanges v3.1 is: https://docs.google.com/document/d/1oPfQ6Xvui0g3xiy1pNiyu5cWFLhvrTVyvYsMVKGyGWM/edit#bookmark=id.95ljmgcjg3gs

You can dynamically turn on or off service defined in your GTFS from GTFS Realtime.

The one limitation here is that the current draft says you can't provide real-time predictions for this service, but IMHO that's still up for discussion if producers/consumers want that feature.

I'm not sure where the ServiceChanges proposal stands today now that DUPLICATED trips and encoded polyline DETOURs are accepted experimental features

The remainder of that ServiceChanges v3.1 proposal is waiting for producers and/or consumers that are interested in implementing the remaining pieces. We wanted to develop a cohesive proposal that covered most use cases but do adoption as experimental features piecemeal as producers/consumers were ready to test and implement.

So the next step if you're interested in GTFS-ServiceUpdates would be to follow the normal change process and open a pull request proposing the features that you'd like to see adopted as experimental.

Note that there is another issue https://github.com/google/transit/issues/113 with a long discussion/evolution of ideas surrounding TripUpdates vs. ServiceChanges.

[darylweinberg]

Apologies for coming so late to this discussion.

Here at CapMetro in Austin we have begun implementing ServiceChanges v3.1 in partnership with Swiftly, who generates our GTFS-RT feed. We can currently cancel trips or blocks, modify departure times, duplicate trips to add service and create detours on the fly. We are working with our trip planning partner (Hacon) to be able to properly handle all scenarios and use updated polylines. We only have commuter rail at the moment but will be standing up light rail in the next few years.

I think the scenarios you describe could be handled in GTFS-RT with what we currently do, possibly duplicating trips and then creating detours on them to handle system splits, until you can update your GTFS Schedule to reflect it. If this scenario is known in advance then updating your GTFS Schedule is the best way to handle it. You could handle short turns by closing stops and modifying departure times in GTFS-RT.

We are looking into implementing GTFS-Service Updates next, before next winter as that is when this scenario most often applies to us.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.