Proposed Best Practice: clarify intended use for CANCELED/SKIPPED TripUpdates VS NO_SERVICE Alerts.

[isabelle-dr]

Problem

This issue comes from a slack conversation in #gtfs-realtime (you can join the Slack here).

In the Realtime spec, producers can use both TripUpdates CANCELED/SKIPPED and Alerts NO_SERVICE to inform re-users that certain trips/stops/routes are not in service.

It's unclear if the intention with Alerts is that trip planners remove the service from the apps altogether VS showing a message to riders.

What we know of re-users currently:

• Transit App modifies routing as a result of NO_SERVICE Alerts (as described in their doc). cc @gcamp
• Citing @bdferris-v2 from Google: Speaking on behalf of Google, I believe we support NO_SERVICE cancellation at the agency, route, route type, stop, and trip level.
• Citing @leonardehrenfried and @optionsome from OpenTripPlanner: OpenTripPlanner doesn't at least support canceling trips through NO_SERVICE alerts as of now. It should be added that there isn't fundamental opposition by the OTP devs, it's just that it was never an important feature for any OTP user to actually change the routing based on alerts.

The GTFS Realtime Best Practices currently say:

When canceling trips over a number of days, producers should provide TripUpdates referencing the given trip_ids and start_datesas 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).

Solution proposed by @derhuerst

Add additional clarification that

• the NO_SERVICE Alert is intended for display to customers, while
• the CANCELED TripUpdates are intended to cause the trips/stop_times to be excluded from routing results

[leonardehrenfried]

cc @whitneys-pm

[IvanVolosyuk]

It is a question between presentation and factual information. Factual information - there is no service at a stop / route / agency, etc. It is a decision for an app developer on how to deliver this information to their users and how to react to the factual information. Different apps have different capabilities and presentations, it is not a data provider decision here unless we want the spec to dictate presentation of transit information.

[leonardehrenfried]

@IvanVolosyuk While I agree with that sentiment, the point of the spec is to facilitate communication between producers and consumers. Since there are competing approaches to achieve a stop being excluded from routing, I think it would be proper to add some language to the spec that manages the reasonable expectations that producers might have.

[gcamp]

How is a producer supposed to cancel let's say a stop for a month? Or, cancel it for this weekend? In a way where route planner can effectively cancel those stops. Providing a trip update of all the trips with one stop time SKIPPED is definitely possible but it's not efficient at all.

It's a case where a producer will have very simple information "Stop X is closed for 3 months", and will create an alert with that exact information. Instead we're proposing that we expand that simple information to all the trips affected, then a consumer parse potentially hundreds of trip update to make sure that stop is cancelled for a laps of time.

Additionally, to me a SKIPPED stop on a trip update doesn't mean the stop is cancelled. It might be skipped for other operational reason (bus bunching, etc). And as an app I would want to display those two cases differently (one is a cancelled stop for a time period, the other is just a skipped stop for one or some trips).

Some might argue that we should parse those trip updates, then figure out that there's a pattern of skipped stops for a sufficient length of time (ex : 5 trips in a row skipped this stop, then we should mark it as cancelled). Even if we ignore the complexity making this process happen, creating the heuristics to figure out if it's one type of cancellation or an other doesn't seems like it's a productive work when the agency already has that information in hand.

Finally, I agree this behaviour should be clarified and formalized, but I don't think saying NO_SERVICE alerts should not change planner/app behaviour without any replacement way of achieving this feature is the way to go.

[dbabramov]

One challenge with the proposed clarification is that producers need to support RT Trip Updates feeds. Not all data producers have the technical capabilities to produce a Trip Updates feed (or produce it with an acceptable level of quality). Therefore cancelling services with a service alert happens to be the only available option in their disposal.

Besides, data providers who want to display information to customers can choose other effect values, e.g. MODIFIED_SERVICE.

[optionsome]

We should also consider what is the time span for cancelling things through realtime updates. If you want to close a stop for 3 months, maybe it makes sense to edit the scheduled data (GTFS) to not have the stop in the schedules for any route. Although, I can see how it can make sense to include the "skipped" stop in the schedules for longer periods of time to clearly communicate to the users that a stop is skipped.

This also touches the topic of planned cancellations. NETEX (as far as I'm aware) has possibility to include cancellations in the planned data, GTFS does not. Planned cancellations in the static data would be a good fit for these longer disruptions.

[miklcct]

It's the producer's responsibility to skip stops in TripUpdate when a service does not call at a stop for any reason. It is just a simple database query on the static GTFS to select all services which call at a particular stop, and StopUpdate objects can be mass produced as a result.