[Realtime] Clarify Trip Update precedence for consumer routing decisions#630
[Realtime] Clarify Trip Update precedence for consumer routing decisions#630tzujenchanmbd wants to merge 2 commits into
Conversation
|
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. |
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.mddescribing 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