Clarify spec: Add definitions to Cause and Effect values and clarify Trip Update precedence for consumer routing decisions#648
Conversation
# This is the 1st commit message: add tripupdate clarification # This is the commit message #2: fixed formatting # This is the commit message #3: Clarify detour description in service alerts Updated detour description for clarity. # This is the commit message #4: Clarify DETOUR effect description in reference.md Updated the description of the DETOUR effect to clarify that it refers to stops not being served. # This is the commit message #5: better detour definition
fixed formatting Clarify detour description in service alerts Updated detour description for clarity. Clarify DETOUR effect description in reference.md Updated the description of the DETOUR effect to clarify that it refers to stops not being served. better detour definition add comma add comma
Wouldn't it be nice to have a clear guidance on whether they should do this or not? At the moment it seems to be "do whatever you want"? I also only see |
|
My comment here still stands. From @tzujenchanmbd's response, the argument that there's flexibility in the guidelines doesn't remove the fact that I have the feeling that anyone considering NO_SERVICE in their routing will do the opposite of what the guidelines suggest. Might as well not have a guideline? |
| | **ACCESSIBILITY_ISSUE** | | ||
| | _**Value**_ | _**Comment**_ | | ||
| |-------------|----------------| | ||
| | **NO_SERVICE** | No transit service to the specified entity(-ies).<br>- For stations or stops, the rider will not be able to board or alight.<br>- For routes, the route will not run.<br>- For trips, those specific trips are cancelled. | |
There was a problem hiding this comment.
Was leaving out station entrances and pathway nodes done on purpose?
There was a problem hiding this comment.
@gcamp yes. The topic of allowing alerts for pathways, entrances, exits is something that has been talked about for a while and we are planning to start that conversation soon. Building one what was mentioned on issue#268, the intent was to clarify some things in the realtime spec (such as here and in #546 ), create documentation to help with implementation and how to deal with use-cases (such as the spec vs RT Guidance and the RT Alerts Guidance), then eventually get to "alerts on pathway data". That conversation can involve all location_types and pathway_modes.
What stops you from sending TU for multiple weeks in advance? Technically there's no blocker on the protocol level that would prevent this. It's a bit verbose, so that might be an indicator to improve TU rather than to (mis)use |
|
I concur with @felixguendling: This dispute has been going on for so long that I frankly don't really care anymore what the standard position is as long as it is clear and the argument is over. |
|
As @leonardehrenfried mentioned, this has been an ongoing discussion for a long time. At the same time, we can also observe that Service Alerts are already widely used in practice, while some aspects of the documentation still need clarification. The current situation can lead to information that is difficult for riders to understand or even incorrect. We (MobilityData) have been trying to find practical solutions that improve the current situation while remaining acceptable to different stakeholders within the community, including this PR, #546, and the Service Alerts Guide, even if these compromise-based solutions are probably not perfect for everyone. One observation from recent discussions is that the community seems to be increasingly recognizing the practical value of using NO_SERVICE as a routing signal. As @felixguendling suggested, perhaps we could explicitly indicate that NO_SERVICE has to be considered a valid input for routing decisions, which should align with what many trip planners already do today. We'd be interested in hearing what others think about making that expectation explicit. However, once we clarify that NO_SERVICE can be used as a routing input, as well as its definition for different entities, a follow-up question is what consumers would do when NO_SERVICE conflicts with TU. This was discussed during the April Working Group Meeting, where the following direction emerged from the discussion:
During the discussion, this direction received support from the producers participating in the meeting, and representatives from both Google and Apple also expressed support in principle. (Meeting notes) Even though there may be situations where consumers choose to prioritize SA instead (e.g. when there is clear evidence that TU is incorrect), I think defining a default behavior can still provide value by establishing a common expectation for handling conflicts. Does this seem like a reasonable balance that the community could align on? |
|
My preference is to put everything routing-related in TU but I can get behind this definition. |
|
MOTIS is currently not considering
Please don't clarify that |
5 participants
Summary
MobilityData is currently developing Service Alerts guidance to help the community use Service Alerts more consistently. As part of this work, we are gathering feedback through the Service Alerts Working Group meeting.
In the Apr 28th, 2026 meeting, we presented and discussed detailed definitions of values for the Cause and Effect fields, drafted here, to make sure that producers are attributing the correct values to real-world cases.
In addition, we discussed how consumers should interpret cases where both Trip Updates and Service Alerts apply but provide conflicting information. The group reached consensus that consumers should by default give precedence to Trip Updates for routing decisions.
Proposed Solution
This PR
Adds a clarification to
feed-entities.mddescribing the expected consumer behaviour when Trip Updates and Service Alerts both apply.While this clarification will also be included in the Service Alerts guidance, we believe it is appropriate to include it directly in the specification as well, in order to make this shared expectation clearer.
Details the definitions for values of Cause and Effect, to make sure that service alerts are correctly categorized.
These changes are intended to clarify definitions and to clarify a principle for expected consumer behaviour, and they do not introduce a new field or functional change. Therefore, I propose that it can proceed to a vote without requiring implementation testing.
Type of change
GTFS Schedule
GTFS Realtime
Additional information
Here is the working group meeting notes
We also plan to add an additional Service Alerts meeting in July to continue discussing guidance around Service Alert usage. Registration page