Do Alerts with NO_SERVICE effect for stop/trip/route impact itineraries shown to riders?

[barbeau]

In past discussions ((1), (2), (3)) the question has come up if Alerts with the Effect of NO_SERVICE are purely informational, or if they should impact the itinerary results shown to riders.

If alerts are purely informational, then the consumer would still show the canceled trip, route, or stop to the user like normal, but would annotate it with the Alert text explaining that the entity doesn't currently have service. For example, if "Route 5" didn't have service, then the consumer would still present the "Route 5" trip option to the rider, potentially as the top option, but indicate that it's not operating.

If alerts affect the itinerary, then the consumer would optimize the itinerary results shown to riders to account for the entity without service. For example, if "Route 5" didn't have service, a consumer may present "Route 3" as the top itinerary option to the user with an explanation that "Route 5" is not operating and therefore "Route 3" is their best choice.

We should clarify what the expected behavior is for consumers so that producers can have proper expectations when publishing NO_SERVICE alerts and some consistency across consumers.

(Note that I'm focusing on what the end user (rider) is experiencing here, and not on the internal implementation details such as whether or not the routing engine returns "Route 5" as the top option and then the results are filtered in the presentation layer so "Route 3" is shown as the top option instead, vs. the routing engine directly returning "Route 3" as the top option. IMHO those are implementation details that we shouldn't address within the spec)

The GTFS-realtime spec on the "Service Alert" page currently says:

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.

Google's documentation on how they interpret Alert Effects is at the bottom of this page:
https://support.google.com/transitpartners/answer/6374472?hl=en&ref_topic=6159819

...as well as in guidelines for "How to cancel a trip":
https://support.google.com/transitpartners/answer/6325970?hl=en&ref_topic=6159819

...and in "Realtime information in routing results":
https://support.google.com/transitpartners/answer/6327328?hl=en&ref_topic=6159819

The 1st link says:

NO_SERVICE: There’s no service on the line or at certain stops, or a specific trip has been canceled. This will trigger Trip Planner to re-route users around the disruption.

The 3rd link says:

We support realtime re-routing based on Trip Updates and Service Alerts with NO_SERVICE effect on Google Maps. Service Alerts messages with effect different than NO_SERVICE will only be annotated with realtime information.

Canceled trips which may be relevant to the user, are displayed as crossed out at the bottom of the results list (after up to 4 available connections). If the canceled trip is however not relevant, for example if it is one instance of a very frequently running trip whose cancelation will not affect significantly the user, then it won't be visualized as part of the results list.

So Google interprets NO_SERVICE alerts as affecting the itinerary.

@gcamp from Transit App in #224 (comment) said:

In Transit we'll mark those services as no running without hiding them completely. The trip planner will also work around those services so you do get the best trip plan with current service.

Sounds like Transit App interprets them similarly to Google.

@tleboulenge @anatolip-rt @gcamp Please feel free to clarify any of the above if needed.

Could other producers and consumers share their interpretation/expectation of Alerts with NO_SERVICE effects?

References:
(1) - #137 (comment)
(2) - #245 (comment)
(3) - #224 (comment)

[skinkie]

I want to shine some light with the multiple way is an issue, @abyrd can you comment too? The following typical happens with departure displays. The problem appears with replacement services for cancelled trips. In order to know that something is a replacement, you would actually need a reference to the original. This relationship typically does not exist in CAD/AVL systems for unknown reasons to me, lets blame lazy developers. When you cancel a trip and have a replacement you want to advertise the replacement and hide the original trip, it is super confusing to show a cancelled trip at 1pm and have the replacement at 1pm that is running. There are numerous reasons that the replacement tail from the riders current perspective is equal to the original trip, while the head of the trip is cancelled or terminated early. Another presentation issue exists if all trips between 1pm and 4pm are cancelled and the first running trip appears at 4:15pm. The least I want to show my customers is the diversity of running trips and not have them masked by cancelled trips.

From a journey planner perspective several issues exists. From an outside perspective several algorithms exists the way they handle cancellations greatly depend. This is important if they can represent a service alert on a cancelled trip ever.

I think it is best to split them in:

1. Real-time is not considered when routing, and is purely applied at presentation. We would threat tripupdates and service alert at the last phase of the planning, as attributes. This would allow the user to see why they cannot make a transfer or why a trip is cancelled. This method will not consider a better way to reach the destination, nor is it able to abuse a delay for a better transfer option.
2. Real-time is the new ground truth. The planner basically runs on the tripupdates feed for the data that is realtime and in scope. It will ignore cancelled trips (because they are cancelled) and come up with alternatives. The main problem with this approach: the user wouldn't have a clue that a trip (or stop) was cancelled, it is never ever considered in the Pareto optimal result, there is just no way a service alert would ever be attached in a usable sense. Sure, if the stop would appear in a trip that is considered you could add this service alert, but if the user dropped off one stop earlier, they are not going to see that next stop.
3. The hybrid approach of both methods. With recent advancements using profile queries (this means: return all planning results between two moments in time) it is relatively easy to combine both methods. You wouldn't have to do a point query (read: a single optimal result) rather you can show everything. By the showing everything approach you gain the ability to show the scheduled but cancelled trip (or stop), therefore service alerts become in reach.

Google has been pushing cancellations by service alerts because they wanted to do their own predictions based on the vehicle positions feed, hence integrating data into their own tripupdates. When they were confronted with the fact that replacements trips for trains were not recovered and their method did not support (partial-)detours the combination of tripupdates and vehicle positions became supported again. Because service alerts cannot be used during the planning (unless integrated with tripupdates) it requires an integration step. So if one would provide vehicle positions and service alerts, this would expect a consumer to make trip updates. GTFS-RT Full suggested that all producers should create a tripupdates feed that has integrated all data (thus cancellations), without the integration step requirement for every consumer.

[gcamp]

@skinkie your concerns seems to be about cancellation of trip. That might have been the main reason Google supported the NO_SERVICE that way but it wasn't the reason we handled NO_SERVICE as cancellation.

In fact, we don't support NO_SERVICE cancellation on trips, only for stops and routes. Our goal in supporting disruptions at a higher level than this. Ex : Orange line is not running unexpectedly, an alert is sent and the trip planner will avoid the Orange line. Same thing on a stop level.

Alerts should still be of relevance to the user. For example, trip cancellation on a bus line with frequent headway should most likely not create an alert, but trip cancellation on a commuter rail line with 1h+ headway probably should.

[skinkie]

In fact, we don't support NO_SERVICE cancellation on trips, only for stops and routes. Our goal in supporting disruptions at a higher level than this. Ex : Orange line is not running unexpectedly, an alert is sent and the trip planner will avoid the Orange line. Same thing on a stop level.

What you are trying to say is that you want to give the operator the option to use a compressed representation (event based) towards your system to cancel a route or stop. That is fine for a GUI or interaction from a person to a system, but not for system to system interaction in a landscape where every system needs to figure out what trips belong to the route_id.

I mean, you could effectively also send a TripDescriptor (route=1, schedule_relationschip=cancelled) to represent the same, but that effectively just bypasses the denormalised information exchange we have standardised. It basically abuses selectors for tripUpdate events, which in my perspective is for machine2machine a bad practise, but a human2machine a good interface design.

Alerts should still be of relevance to the user. For example, trip cancellation on a bus line with frequent headway should most likely not create an alert, but trip cancellation on a commuter rail line with 1h+ headway probably should.

Agreed, this is kind of a good way to distinguish applications based on their quality and understanding of the data.

[tleboulenge]

We're currently updating our public documentation so it will reflect more accurately how cancellations are processed and displayed. On Google Maps, a cancelled trip is sometimes not displayed at all (option #2 from skinkie's post), sometimes displayed as "not running" (option #3). I think it depends if it was declared in a TU feed or an Alert with NO_SERVICE, which may not be the smartest heuristic but at least it gives producers control over how it's displayed (... which will arguably be true once the updated documentation is online).

Now it's a good question whether that choice of display should be given to the producer or the consumer. Beyond that, having both capabilities seems a bit redundant. I would see that kind of information a better fit for the TU feed (alongside other service disruptions / adjustments) but there's also a convenience factor for having it in Alerts (e.g. ability to create an alert manually even if no TU feed is set-up)

We also handle NO_SERVICE on other entities than trips, with its own lot of ambiguity, typically for a stop: if a stop is closed between 4pm and 5pm, exactly what trips does that affect? The one that was scheduled to stop there at 3:58 but is running 3 min late? But not if it's back to being 1 min late?

In summary, I would prefer to group structured data in the TU feed (= data that affects routing), and informational data in the Alerts feed (= text that is displayed to users), but going that way will definitely break current behaviour and expectations.

[paulswartz]

Our in-house software Concentrate (https://github.com/mbta/concentrate) does this processing: NO_SERVICE and DETOUR alerts are turning into SKIPPED stops and CANCELED trips depending on the alert. We also have internal systems which use the service alerts to influence the generated predictions.

However, we don't want external entities doing that processing for us, as we have less control over whether their processing matches what we meant by the alert.

[barbeau]

@paulswartz So would you agree with this statement by @tleboulenge then?

I would prefer to group structured data in the TU feed (= data that affects routing), and informational data in the Alerts feed (= text that is displayed to users),

[skinkie]

@paulswartz So would you agree with this statement by @tleboulenge then?

I understand @paulswartz statement as "we use service alerts internally to communicate to other systems" hence making a case to use GTFS-RT "internally" for a different purpose than an "external" publication.

[paulswartz]

We use them for both internal and external communication. But I wouldn't want external consumers to make assumptions about what the Service Alerts mean for real-time routing: that's our responsibility and we include that in the TripUpdate/VehiclePosition data we provide.

[sam-hickey-arcadis]

We see at least three ways to show no service at the trip and/or stop level:

(1) In TripUpdates feed with the trip shown with schedule_relationship = CANCELED and/or stop(s) shown with schedule_relationship = SKIPPED.
(2) In Alerts feed with effect = NO_SERVICE and consumers reflecting no service in routing/trip plans and optionally showing text of alert
(3) In Alerts feed with effect = NO_SERVICE and consumers showing text of alert with no changes to routing/trip plans

Although it’s not explicitly stated in the TripUpdates spec, we’ve always thought TripUpdates were more for near-term real-time info (generally within the next few hours) whereas Alerts are more for communicating longer-term changes. While we see how (1) meets the spec, it presents some undefined things. For example, how far into the future should a producer include cancelled trips or skipped stops in TripUpdates? Some may suggest that, for example, any cancellation or stop closure lasting more than 7 days should be represented in the GTFS schedule. While this sounds ok in theory, many transit agencies we work with do not have the resources (systems and/or staffing) to make changes to their GTFS schedule this frequently. And is the size of feeds going to be an issue? In the case of a stop closed for one week, that can be accomplished pretty compactly in Alerts while TripUpdates would require a much more verbose representation.

It has also been our expectation (like @stevenmwhite commented at #245 (comment)) as a producer of alerts feeds that alerts would affect routing/trip plans ((2) above). Exactly how this is achieved, and the type of associated messaging shown to users, would be up to each consumer, but the discussion here and at #245 is making it clear that consumers use alerts feeds in different ways when it comes to routing.

In addition to producing alerts feeds, we also produce TU and VP feeds and consume all three types of feeds, so it would be helpful to reach some kind of consensus on best practices for how no service should be communicated. Here is one way of thinking about scenarios and feeds (for feeds created “today”):

	Trip Updates	Service Alerts
Trip is cancelled today
Trip is cancelled tomorrow
Trip is cancelled a week from today
Stop is skipped today
Stop is skipped tomorrow
Stop is skipped a week from today

There are other important scenarios not listed above (for example, a stop is skipped all day, every day for the next week), but the scenarios above provide a starting point for thinking about where trip cancellations and skipped stops should be shown.

It would be good to get opinions from producers and consumers about whether trip planners should incorporate cases of no service into itineraries from one of the two feeds only or both?

Our opinion is that, in a perfect world, trip planners would give precedence to trip updates for routing purposes if a particular trip and/or stop is included in trip updates and service alerts (and therefore using the alert for informational purposes only) but if a trip and/or stop is shown as having no service in the alerts feed only then the alert would impact itineraries. This wouldn’t necessarily work for the case shared by @paulswartz where a producer doesn’t want consumers to apply alerts to trip plans. We see this as an important type of behavior to allow a producer to control, so more discussion about this (including perhaps adding a new field in the service alerts feed header to allow a producer to define this behavior) is likely needed.

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