Skip to content

[Realtime] Clarify Trip Update precedence for consumer routing decisions#630

Open
tzujenchanmbd wants to merge 2 commits into
google:masterfrom
MobilityData:Alert-vs-TripUpdate
Open

[Realtime] Clarify Trip Update precedence for consumer routing decisions#630
tzujenchanmbd wants to merge 2 commits into
google:masterfrom
MobilityData:Alert-vs-TripUpdate

Conversation

@tzujenchanmbd
Copy link
Copy Markdown
Collaborator

@tzujenchanmbd tzujenchanmbd commented May 4, 2026

Context

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 28 meeting, 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 change

This PR adds a clarification to feed-entities.md describing the expected consumer behavior 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.

Because this change clarifies a principle for expected consumer behavior, and does not introduce a new field or functional change, I propose that it can proceed to a vote without requiring implementation testing.

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

@tzujenchanmbd tzujenchanmbd changed the title Clarify Trip Update precedence for consumer routing decisions [Realtime] Clarify Trip Update precedence for consumer routing decisions May 4, 2026
@tzujenchanmbd tzujenchanmbd added GTFS Realtime Issues and Pull Requests that focus on GTFS Realtime Change type: Non-Functional Refers to important updates to the specification that do not significantly affect functionalities. labels May 4, 2026
@gcamp
Copy link
Copy Markdown
Contributor

gcamp commented May 4, 2026

Sorry I couldn't be there at the workshop! I signed up and completely forgot to add to add my calendar.

The proposal makes sense at first glance, but I'm not sure it works in practice. The problem is that alerts and TripUpdates generally don't work on the time window. TU is generally a couple hours in the future and alerts are multiple weeks in advance.

In a situation where a stop is marked as NO_SERVICE for a week, but the TripUpdates shows regular departure for the next hour, are we expected to show service in the next hour and then all of a sudden shows as closed in an hour? I understand that NO_SERVICE alerts can create false positives, but I don't think this proposal really makes the end situation better. If both are present, I feel the longer timespan one (alert) should have priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Change type: Non-Functional Refers to important updates to the specification that do not significantly affect functionalities. GTFS Realtime Issues and Pull Requests that focus on GTFS Realtime

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants