cc @whitneys-pm

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.

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

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.

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.

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.

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.