Add Cause and DayTimePeriod to GTFS-TripModifications

[ckraatz]

Describe the problem

There seems to be information being entered by agency staff but missing from the GTFS-TripModifications messages. SimplifyTransit has spoken with agencies about this data, and we'd like that information included in the Trip Updates feed for all Consumers. Specifically:

• The Cause for the Modification
• The days and time periods when the Modification is happening (I'm calling this DayTimePeriod for lack of a better term), if it's not all day during the service_dates range (common with construction-related detours)

Use cases

This would allow Consumers to understand more clearly how and when to display an alert to riders, as well as clearly and transparently link a Trip Modification to a related Service Alert.

Without being specific, as we are with other agency entries that lead to Trip Modifications data, there's ambiguity that negatively impacts riders.

Proposed solution

SimplifyTransit isn't a producer of this data, so I'd look to GTFS-TripModifications Producers to recommend the best solution. Here's what I have in mind so far:

1. Add a TripModifications.Cause for each Modification, using the same values from ServiceAlerts.Cause for consistency and clarity between the data feeds. Specify that any Service Alerts related to this Trip Modification must use the same Cause value.
2. Expand TripModifications.service_dates to include days of the week and time ranges within those days when the Modification is happening (I'm calling this DayTimePeriod for lack of a better term), if it's not all day during the service_dates range (common with construction-related detours).
3. These fields would be Optional, but the spec would Require that Producers who give agency staff fields to enter this structured data must provide that data publicly in the Trip Updates feed. If a Producer doesn't give agency staff a way to enter that data, they are recommended to create those fields to supply this data.

Please suggest better approaches and solutions, particularly if you're familiar with how agencies create this data with your product, or will in the future.

Additional information

No response

[stevenmwhite]

Curious whether linking a TripModification to and Alert directly would be a good approach? Rather than looking for overlapping causes, date/time, and affected routes/stops to assume that a trip modification is related to an alert, would specifying that "this modification is related to this (or these) alerts" more explicitly make sense?

[ckraatz]

@stevenmwhite the linkage is already in the spec (although I'm not clear how the Trip Updates producer intends to get the GTFS-ServiceAlert_id supplied by another vendor). I'm considering proposing a mirroring field in the Service Alerts spec.

https://gtfs.org/documentation/realtime/reference/#message-modification

service_alert_id - String - Optional - One - An id value from the FeedEntity message that contains the Alert describing this Modification for user-facing communication.

[stevenmwhite]

Ah. Sorry I wasn't looking at the spec at the time. Feels like adding cause to the modification would be duplicative then.

Of course, you do bring up the point about "what if the feeds are by different producers" which is something that I don't think GTFS really considers...

[ckraatz]

Would it be any more duplicative than referencing a service_alert_id in both the Service Alerts and Trip Updates feeds?

Swiftly, if I understand correctly, has agency staff enter a "Reason" that may or may not be linked to the Cause of an alert. Most commonly "construction" or "event," which my proposal to add SPECIAL_EVENT to Causes would help with.

Swiftly also has staff enter some sort of day and time information, in addition to the dates, but that's not translated into the Modification data publicly. That information would inform creation of multiple active_periods for an Alert.

I'm not sure how this works in Clever Devices' Detours module or other CAD/AVL systems, but I'd like Trip Updates Producers to follow the precedent set with all the other detour information entered by agency staff. The only information that's missing is what's essential for creating a good Service Alert. This proposal corrects that oversight.

"what if the feeds are by different producers"

That's exactly the point of these proposals. To achieve widespread adoption and the interoperability the community support, GTFS-realtime feeds need to interoperate with each other in an open architecture. That's true whether they're all produced by one vendor or by multiple vendors.

[skinkie]

Curious whether linking a TripModification to and Alert directly would be a good approach? Rather than looking for overlapping causes, date/time, and affected routes/stops to assume that a trip modification is related to an alert, would specifying that "this modification is related to this (or these) alerts" more explicitly make sense?

You just reinvented SIRI Situation Exchange ;-) Define complete scenario's in system 1, prediction system know about them, and recomputed estimated arrivals.

[doconnoronca]

Doesn't the list of affected trip_ids define the time period?

[ckraatz]

Doesn't the list of affected trip_ids define the time period?

@doconnoronca There are ways to reverse engineer the time period from the trip_ids, and we'll do that in the absence of explicit data. I just worry that would require making certain assumptions that could be wrong or aren't simple for riders.

Am I overthinking it?

For example:

• What if the first detoured trip on a Thursday starts at 6:47am and is expected to reach the start_stop_selector at 7:03am
• The last detoured trip on that Thursday is expected to reach the end_stop_selector at 3:47pm
• When does the detour start and end that day?
• We could look in stop_times and use the propagated_delay to get times for the start/end_stop_selector stops and put them in the active_period and text of the Alert, but will they match what the dispatcher entered into Swiftly, OnRoute, Clever Devices, etc?
• The propagated_delay makes this time period dynamic and unpredictable - what if it increases/decreases during the day or from day to day, making the start/end different and unclear to riders?
• What if at 5am that Thursday one of those affected trips is canceled? Would we factor that reverse-engineering into the day and time period, or leave it as-is?

If a dispatcher takes the time to enter time range information specifically, why not expose that information explicitly and publicly in the data?

[doconnoronca]

Doesn't the list of affected trip_ids define the time period?

@doconnoronca There are ways to reverse engineer the time period from the trip_ids, and we'll do that in the absence of explicit data. I just worry that would require making certain assumptions that could be wrong or aren't simple for riders.

Am I overthinking it?

It would be better to add the time period to the alert message, which are meant to be shown to the user and are more widely supported.

[ckraatz]

add the time period to the alert message

That's what SimplifyTransit is trying to do, but if the time period isn't available in GTFS-TripModifications we can't do that as accurately.

Our Automated Detour Alerts use GTFS-TripModifications to create the best alert possible, including attaching an Automated Map Image showing the closed stops, replacement stops, detour and original route. Plus we translate all alerts accurately, for equity.

If CAD/AVL vendors publishing GTFS-TripModifications withhold the cause and time period information staff have entered, we can't give our customers and their customers the best alerts possible.

We can consume and use the Cause from a CAD/AVL GTFS-ServiceAlerts feed, if it's there. But the only way to communicate M-Th 7am to 4pm is in text. We'd rather have that as structured data explicitly created by a dispatcher.

[doconnoronca]

It would be better to add the time period to the alert message

@doconnoronca by that logic, wouldn't it also be better to only add the service_dates to the Alert too?

It would be better if there were always a linked alert message, but that isn't guaranteed.

[ckraatz]

It would be better if there were always a linked alert message, but that isn't guaranteed.

@doconnoronca that's another part of the spec I'm confused about: how will the Trip Updates Producer find and enter the service_alert_id if the Alerts feed is produced by another vendor?

Should we be adding modification_id to the GTFS-ServiceAlerts spec, in case the Trip Updates Producer doesn't have a way to link the two feeds?

Sure, it's common for all three feeds to come from the same vendor, but that's certainly not necessarily the case. And that hasn't necessarily led to the best outcome for agencies or riders. I expect more and more agencies to have GTFS-ServiceAlerts hosted by a different Producer than their Trip Updates and VP producer, because those are very different areas of expertise.