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

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?