Keeping alerts targeted & specific when detours are reflected in schedule data

[lauramatson]

We have an issue as a data producer and consumer. (Our customer information tools are all built around our GTFS data.)

When detours and stop closures are not reflected in the schedule data (i.e., closed stops are included in stop_times.txt), we close the stop via a ServiceAlert. It’s straightforward that the closed stop_id’s can be noted as informed_entity’s, the schedule_relationship in TripUpdates is skipped, etc.

Ideally, however, we want planned detours & stop closures to be reflected in schedule data. Trip plans, schedules, and real-time predictions are more accurate within our own tools and in other apps when the static files reflect the patterns the buses will actually travel and the stops the buses will actually serve.

Since it is still a detour (even though it’s in the schedule), we need to provide the Alert information. The challenge we have is that the alert gets updated so that the informed_entity is the route, since the closed stops are no longer referenced in stop_times.txt.

We tried retaining the stops in stops.txt while removing them from stop_times.txt to keep the alert more targeted, but that was a deal-breaker for a major consumer using our realtime feeds at all. If there was consensus on that approach it would solve part of our issue – it’s hard to parse a long list of route-level alerts – but it would leave some gaps.

These are our goals:

1. When a customer requests real-time information for closed stop_id, or is at a stop with a real-time sign configured to display information for that stop_id, they get the relevant alert information. In order to achieve this, we need the alert to reference the closed stops in some way.
2. Alert information is geographically targeted to any temporary stops and the stops before and after the detour (i.e., the places a customer may be directed to if their normal stop is closed). When a customer plans a trip directing them to a temporary stop or the alternate stop before/after the detour, the alert shows up. When a customer plans a trip elsewhere on the route, the irrelevant alert is not displayed. Customers do not need to parse a long list of alerts that may not impact them.

This is the approach we are considering: When detours are reflected in the schedule data, update the alert so:

• The stops before and after the detour and any temporary stops created as part of the detour are the new informed entities
• The effect isn’t “DETOUR” but “OTHER” (so it’s clear that these stops shouldn’t be skipped)
• Adding a new field where closed stops can be listed (maybe “closed_stops”)
• Retaining these closed_stops in stops.txt for reference

Example

BEFORE / UN-SCHEDULED DETOUR

“effect”: “DETOUR "informed_entity": [ { "agency_id": "0", "route_type": 3, "route_id": "18", "stop_id": "12345", [<--- THIS IS THE CLOSED STOP] "direction_id": 1,

AFTER / DETOUR IN SCHEDULE

“effect”: “OTHER” "informed_entity": [ { "agency_id": "0", "route_type": 3, "route_id": "18", "stop_id": "12344” [<-- This would be for regular route stops before and after detour and any temporary stops] "direction_id": 1, “closed_stops:” “19294”

Feedback Have others dealt with this issue? Are there other approaches we should consider? Anything that would make this more useful to other consumers and/or replicable for other producers?

[ehowington]

@lauramatson thanks for bringing this up - It's my opinion that this also would apply to entire routes that may be suspended, and raise the question of 'how do we indicate services [stops, routes] are suspended but still exist?" This came up early in the pandemic (#224).

There are a few questions that are helpful to ask when considering the goal of informing riders of suspensions/closures:

1) For trip planners riders are being directed to active stops and routes, so while a rider may be familiar with another route or stop, the goal of the trip planner is to provide them an itinerary that meets their origin and destination requirements at the prescribed time.

2) For analysis and planning GTFS consumers/users, the values for routes and stops, while still available in their respective files, are absent in trips and stop_times which may hinder system analysis but also provides a more accurate picture of what service actually look/ed like on a given service day/period.

3) For CAD/AVL consumers of static and producers of GTFS-rt, my understanding is that the need is primarily to exactly map the current service levels as closely as possible - so ensuring that only active service levels are described is valuable.

4) For mapping applications that display information about stops and routes, this may be the place that would most benefit from the ability to apply alert information to an entity itself, even if that entity is not in use in trips or stop_times.

Since 1-3 are already being handled by including the detour in your static GTFS, that leaves 4 as having some room to grow a bit in my opinion. To be able to apply an alert to a stop or route (or even agency) that is not referenced in trips or stops_times may more concretely address your workaround. This is contingent on how mapping applications actually display stops and routing, and whether users can interact with them in any meaningful way (such as clicking a stop to pull up more info about it.) The stops that are active as temporarily serving the place of another stop can have an alert applied to them, though I am not certain how helpful 'DETOUR' or 'STOP MOVED' are in these instances.

Technically an alert can be published to a stop or route, even if that stop or route is not being expressed in any trips or stop_times, but I do not believe mapping applications which ingest alerts are able to display them to riders, but I could be wrong.

[lauramatson]

Thanks @evantrillium for your comments!

For Trip Planning - If I am going to be directed to a different stop than usual via the trip plan results, I would like to know why. Without an alert, I may think the trip planner is off or giving me bad information. I think it's useful to include the alert even if stop_times.txt has been updated and riders are being directed to active stops only.

Likewise, for riders who have saved favorite stops (for realtime or schedule information), we want to be able to display the alert information (i.e., why the stop is closed, expected duration, etc.). I think the most straightforward way to do this would be to reference the closed stops in the alert itself.

[skinkie]

For Trip Planning - If I am going to be directed to a different stop than usual via the trip plan results, I would like to know why. Without an alert, I may think the trip planner is off or giving me bad information. I think it's useful to include the alert even if stop_times.txt has been updated and riders are being directed to active stops only.

This is a comment that always pops up for advanced riders that think they can outsmart the journey planner :)

Likewise, for riders who have saved favorite stops (for realtime or schedule information), we want to be able to display the alert information (i.e., why the stop is closed, expected duration, etc.). I think the most straightforward way to do this would be to reference the closed stops in the alert itself.

What about being able to reference something in tripUpdates which actually models the detour and gives a one-to-one relationship?

[sam-hickey-ibigroup]

Going back to one of the points from the original post, it seems one important question to answer is whether the GTFS-realtime specification allows an alert to have an informed_entity that references values in GTFS when those values do not have scheduled service. For example, a route_id may exist in routes.txt but the route may be temporarily suspended or a stop_id may exist in stops.txt but never show up in stop_times.txt because the stop is closed.

Our reading of the GTFS-realtime specification and EntitySelector definition is that this is allowed if a GTFS entity (or combination of GTFS entities) matches an entity in the GTFS feed. For example, we don’t see anything in the specification that makes it so an alert’s informed_entity cannot only include a route_id that is in the GTFS routes.txt but does not have any scheduled service. We also don’t see anything that prevents a case where an informed_entity only includes a stop_id that is in the GTFS stops.txt but does not have any scheduled service.

One scenario that is more of a grey area is whether an informed_entity is allowed to reference a route_id AND stop_id where this route_id does not have any scheduled trips at this stop_id. The definition of EntitySelector says “in order for an alert to apply to an entity in GTFS it must match all of the provided EntitySelector fields”. Does this mean if a route_id and stop_id are included in an informed_entity but they do not have scheduled service in the GTFS then this informed_entity should be ignored by consumers? Or is it at an error that makes this particular alert invalid and therefore consumers should not display the entire alert even if the alert has at least one other valid informed_entity?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[skinkie]

Keep open

[github-actions[bot]]

This issue has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.