Add activities field to informed_entity in GTFS-realtime alerts

[natekauf]

Describe the problem

It is not possible to model certain common operational scenarios with the existing GTFS-RT alerts spec. When certain alerts are published, such as alerts describing rail suspensions between specific stations or alerts describing bypassed stops, the information available to consumers about what services are unavailable in a given direction at a given station is limited and can lead to misinformation and/or rider confusion.

Use cases

Theoretical examples

Case 1. Service suspension in both directions between specific stations

Service is suspended between Station 3 and Station 5. Service is available from Station 3 toward Station 1 and vice versa, and service is available from Station 5 toward Station 7 and vice versa.

If service normally runs in both directions between Stations 1 and 7, but there is a suspension between Stations 3 and 5, the most logical available effect values are NO_SERVICE or REDUCED_SERVICE, where the informed_entities are Stations 3, 4, and 5. However, both of these effects leave uncertainty around what riders can or cannot do at Stations 3 and 5:

• With an effect of NO_SERVICE, it would be reasonable for consumers to interpret that there is no service available in any direction at Station 3 or at Station 5, when in fact there is service between Stations 1 and 3 and there is service between Stations 5 and 7.
• With an effect of REDUCED_SERVICE, it would be reasonable for consumers to interpret that some service is still available between Stations 3 and 5, when in fact no service is available.

Case 2. Bypassed stops

Stations 3, 4, and 5 are temporarily closed. Riders cannot board or exit at these stations, but passenger trains can ride through them.

If specific stations’ entrances and exits are closed due to police activity, and riders can ride through those stations but not board or exit there, there is no way to convey this unambiguously through the existing alert spec.

• With an effect of NO_SERVICE, it would be reasonable for consumers to interpret that there is no service available at all at those stations, when in fact there is service moving through those stations.
• With an effect of REDUCED_SERVICE, it is not possible for consumers to know in what way service is reduced, i.e. riders cannot board or exit at the affected stations.

Real-world example: Rail suspension with effect of NO_SERVICE

A suspension with an effect of NO_SERVICE appears in third-party applications as unavailable service between the affected stations. The limit stations of the suspension appear as having no service at all, even to and from adjacent, unaffected stations. This implies to riders that they must find another way to the limit stations from adjacent, unaffected stations, when in fact they can take normal rail service between those stations.

Google Maps

• Suspension limits: North Station to Kenmore (MBTA in Boston, MA)
• At North Station, northbound trips (away from the suspension) are shown as cancelled and predictions are not available, despite these trips being possible and predictions being available.

Apple Maps

• Suspension limits: Back Bay to Roxbury Crossing (MBTA in Boston, MA)
• Service between Jackson Square (not part of the suspension) and Roxbury Crossing (a limit station of the suspension) is shown as unavailable, despite it being available.

Transit App

• Suspension limits: North Station to Jackson Square (MBTA in Boston, MA)
• Service between Jackson Square (a limit station of the suspension) and Stony Brook (not part of the suspension) is shown as unavailable, despite it being available.
• Service between North Station (a limit station of the suspension) and Community College (not part of the suspension) is shown as unavailable, despite it being available.

            

Real-world example: Rail suspension with effect of REDUCED_SERVICE

A suspension with an effect of REDUCED_SERVICE appears in some third-party applications as seemingly normal service, with an unassuming alert that reads “Reduced service”, and details (upon tapping) that describe the limits of the suspension, specifying that service is actually unavailable.

Google Maps

            

Apple Maps

            

Transit App

                        

Counter-perspectives

Only create informed_entities for the stations with absolutely no service

An argument could be made that in Case 1 above, only Station 4’s stops should be listed in informed_entities, and Station 3 and Station 5’s stops should not be in informed_entities at all, because Stations 3 and 5 do have some service.

We don’t believe this solution provides consumers with sufficient information to be helpful to riders. A single informed_entity at Station 4 could be reasonably interpreted as either a suspension of service between Station 3 and Station 5 or a simple bypass of Station 4 with full service at Stations 3 and 5. Additionally, if Stations 3 and 5’s stops are not informed_entities, providing stop-specific information for those stations describing what service is available would not be possible.

Perhaps more material, if service were suspended between only Station 3 and Station 4, it is unclear how that suspension could be conveyed to consumers at all using this paradigm.

Transit App: A suspension between
Park Street and Government Center,
with informed_entities at both, is
presented as a station bypass

Create multiple alerts for one service disruption

An argument could be made that in Case 1 above, there should be multiple service alerts: one with an effect of NO_SERVICE to describe the complete lack of service at Station 4, and one or two with an effect of REDUCED_SERVICE to describe the reduced service at Stations 3 and 5.

However, creating multiple alerts for one service disruption has multiple drawbacks:

• This implies that there is more than one disruption occurring when there is not. A full list of alerts along a route might include multiple alerts for a single disruption, leading to undue confusion and concern about how disrupted the route truly is.
• An effect of REDUCED_SERVICE at Stations 3 and 5 still provides no insight into what riders can and cannot do at those stations, and in what directions they can travel to or from those stations.

Proposed solution

We propose the addition of a new activities field within informed_entity in the GTFS Realtime Alert spec. This field would have enumerated values of BOARD, EXIT, and RIDE, which describe the rider activities that are unavailable at a given stop.

Case 1 solution

If we take the suspension scenario above, we can assign affected activities to each stop within each of the stations where service is affected by the suspension:

• Stop 3-7: ["BOARD", "RIDE"]
• Stop 3-1: ["EXIT", "RIDE"]
• Stop 4-7: ["BOARD", "EXIT", "RIDE"]
• Stop 4-1: ["BOARD", "EXIT", "RIDE"]
• Stop 5-7: ["EXIT", "RIDE"]
• Stop 5-1: ["BOARD", "RIDE"]

informed_entity.activities in red text

Sample of a GTFS-Realtime alert with informed_entity.activities:

 {
      "id": "123456",
      "alert": {
        "effect": "NO_SERVICE",
        "effect_detail": "SUSPENSION",
        "cause": "TECHNICAL_PROBLEM",
        "cause_detail": "TRACK_PROBLEM",
        "header_text": {
          "translation": [
            {
              "text": "Orange Line service is suspended between Station 3 and Station 5 due to a track problem",
              "language": "en"
            }
          ]
        },
        "description_text": {
          "translation": [
            {
              "text": "",
              "language": "en"
            }
          ]
        },
        "severity_level": "SEVERE",
        "active_period": [
          {
            "start": 1748402460,
            "end": 1748409744
          }
        ],
        "informed_entity": [
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "3-1",
            "direction_id": 0,
            "activities": [
              "EXIT",
              "RIDE"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "4-1",
            "direction_id": 0,
            "activities": [
              "BOARD",
              "EXIT",
              "RIDE"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "5-1",
            "direction_id": 0,
            "activities": [
              "BOARD",
              "RIDE"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "3-7",
            "direction_id": 1,
            "activities": [
              "BOARD",
              "RIDE"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "4-7",
            "direction_id": 1,
            "activities": [
              "BOARD",
              "EXIT",
              "RIDE"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "5-7",
            "direction_id": 1,
            "activities": [
              "EXIT",
              "RIDE"
            ]
          }
        ]
      }

Case 2 solution

If we take the station bypass scenario above, we can assign the same affected activities (BOARD and EXIT) to each stop within each of the stations that are bypassed:

• Stop 3-7: ["BOARD", "EXIT"]
• Stop 3-1: ["BOARD", "EXIT"]
• Stop 4-7: ["BOARD", "EXIT"]
• Stop 4-1: ["BOARD", "EXIT"]
• Stop 5-7: ["BOARD", "EXIT"]
• Stop 5-1: ["BOARD", "EXIT"]

informed_entity.activities in red text

Sample of a GTFS-Realtime alert with informed_entity.activities:

 {
      "id": "123457",
      "alert": {
        "effect": "NO_SERVICE",
        "effect_detail": "STATION_BYPASS",
        "cause": "POLICE_ACTIVITY",
        "cause_detail": "POLICE_ACTIVITY",
        "header_text": {
          "translation": [
            {
              "text": "Orange Line trains will not stop at Station 3, Station 4, or Station 5.",
              "language": "en"
            }
          ]
        },
        "description_text": {
          "translation": [
            {
              "text": "",
              "language": "en"
            }
          ]
        },
        "severity_level": "SEVERE",
        "active_period": [
          {
            "start": 1748402460,
            "end": 1748409744
          }
        ],
        "informed_entity": [
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "3-1",
            "direction_id": 0,
            "activities": [
              "BOARD",
              "EXIT"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "4-1",
            "direction_id": 0,
            "activities": [
              "BOARD",
              "EXIT"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "5-1",
            "direction_id": 0,
            "activities": [
              "BOARD",
              "EXIT"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "3-7",
            "direction_id": 1,
            "activities": [
              "BOARD",
              "EXIT"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "4-7",
            "direction_id": 1,
            "activities": [
              "BOARD",
              "EXIT"
            ]
          },
          {
            "agency_id": "1",
            "route_type": 1,
            "route_id": "Orange",
            "stop_id": "5-7",
            "direction_id": 1,
            "activities": [
              "BOARD",
              "EXIT"
            ]
          }
        ]
      }

Additional information

The MBTA (@natekauf, @jfabi), in partnership with our alerts tooling vendor Arcadis (@dan-engler-arcadis), has been using activities in informed_entities in our enhanced GTFS feed in our production environment for several years, and it has been integral in enabling internal tools to solve the problems described above. We are excited by the prospect of third-party applications being able to present the same kind of nuances in service disruptions.

The MBTA and Arcadis have also extended activities to satisfy other use cases. Beyond BOARD, EXIT, and RIDE, we use activities to describe access-related activities that are affected by an alert. For example:

• An alert about elevator maintenance that would disrupt wheelchair use while boarding or exiting would include USING_WHEELCHAIR in its activities.

Arcadis’s TRANSIT-alerts GTFS-realtime documentation section on activities (pages 15-16) includes specifics about the other alert activities related to facilities, namely USING_WHEELCHAIR, USING_ESCALATOR, BRINGING_BIKE, STORE_BIKE, and PARK_CAR, and the hierarchical nature of activities.

Examples of activities can be found in our live enhanced GTFS feed here: https://cdn.mbta.com/realtime/Alerts_enhanced.json. Documentation of the feed can be found here.

[skinkie]

While I do not support this proposal, following feedback.

The terminology for BOARD and EXIT does not follow GTFS terms as pick up and drop off. This makes it inconsistent.

[skalexch]

@natekauf there definitely is an ambiguity between both cases when representing NO_SERVICE alerts in GTFS-RT.

TLDR:

• NO_SERVICE should be clarified in the spec. Usually, it means that the station (or the platform) is closed and the train will not run through it. It is different to a station bypass.
• The current spec can handle a station bypass by indicating through informed entities that there is no service to the entrances and exits of a platform that is bypassed. A less-than-ideal solution for now.
• It might be possible to introduce an effect like STATION_BYPASS which indicates that a train is running through but not stopping at stations. This is to remove confusion around NO_SERVICE for station-based routes.

---

We tried to represent both cases using the current GTFS-RT capabilities.

Usually (in real-world cases), NO_SERVICE alerts for trains mean that the train will not pass through the stations (that a segment is closed). By this assumption, a possible way of differentiating between both cases is:

Case 1: Service suspension in both directions between specific stations
Initially, we can set up

“informedEntities”: [
{“stopId”: “stop_3_1”,},
{“stopId”: “stop_3_7”,},
{“stopId”: “stop_4_1”,},
{“stopId”: “stop_4_7”,},
{“stopId”: “stop_5_1”,},
{“stopId”: “stop_5_7”,},
]

The route_id and direction_id can also be specified if the stop_ids are not split by direction.

The segment from station 3 to 5 is closed. However, the riders should be able to:

• Board the train at stop_3_1 to go to station 1.
• Exit from the train at stop_3_7 coming from station 1.
• Board the train at stop_5_7 to go to station 7.
• Exit from the train at stop_5_1 coming from station 7.

So practically, only station 4 is closed and unreachable. Each stop_id (platform) in the limit stations 3 and station 5 is actually used (Eg. The rider cannot use stop_5_7 if they come from station 1 because the train will stop at station 3. However, the rider can use stop_5_7 if they are starting at station 5 and going to station 7.)

For this to work in GTFS-RT, all stops of station 3 and station 5 should NOT be included.

“informedEntities”: [
{“stopId”: “stop_4_1”,},
{“stopId”: “stop_4_7”,},
]

This tells the consumer that all platforms in station 4 are closed. From a routing POV, a trip planner should be able to route the rider to station 3 if they come from station 1, but it should not be able to do so when coming from station 7.

Note: Sometimes consumers use informedEntities to show the alert to the user on a station-level. ie. When planning a journey at station 5, the user would see the alert, despite Station 5 not being closed. In that case, another passive alert (eg. effect=OTHER_EFFECT) can be set up including the limit stations 3 and 5 only, just to inform the user.

Case 2: Bypassed stations (train runs but does not stop)

“informedEntities”: [
{“stopId”: ..,}
… (all the ids for exits and entrances to the impacted stations).
]

When the informed entities say that the access is blocked to stations through closing exits and entrances, consumers can interpret this as: there is service (train is passing) between stations 3 and 5 but the rider cannot go inside the stations or exit them.

In this case, there is no need to think about boundary stations because each of the bypassed stations behaves similarly.

In both cases, the boundary stations can be handled with the current spec. But the issue resides in having to use hackish methods to indicate a station bypass effect.

[natekauf]

Thank you for the thoughtful response, @skalexch!

Note: Sometimes consumers use informedEntities to show the alert to the user on a station-level. ie. When planning a journey at station 5, the user would see the alert, despite Station 5 not being closed. In that case, another passive alert (eg. effect=OTHER_EFFECT) can be set up including the limit stations 3 and 5 only, just to inform the user.

The prospect of creating multiple alerts for one service disruption is briefly discussed above. We feel strongly that this wouldn't be an ideal way to handle this situation, because it implies that there is more than one disruption occurring when there is not (there is no official way to "link" alerts as relating to the same disruption). A full list of alerts along the route / route status (e.g. https://www.mbta.com/schedules/CR-Fairmount/timetable) would include multiple alerts for the single disruption, leading to undue confusion and concern about how disrupted the route truly is.

When the informed entities say that the access is blocked to stations through closing exits and entrances, consumers can interpret this as: there is service (train is passing) between stations 3 and 5 but the rider cannot go inside the stations or exit them.

In this case, there is no need to think about boundary stations because each of the bypassed stations behaves similarly.

In both cases, the boundary stations can be handled with the current spec. But the issue resides in having to use hackish methods to indicate a station bypass effect.

It does seem like adding activities to informed_entities with stops would make the situation you describe above much clearer for consumers. Adding a STATION_BYPASS effect is probably a good idea too.

[gcamp]

The big elephant in the room for this proposal, to me, is that—as far as I understand—it’s mainly intended for behavior change rather than for information display to the user. And using alerts for behavior change is not something that’s been agreed upon.

We can debate whether NO_SERVICE should be used in this way or not, since it’s already used like this in practice. However, it seems to me that introducing new alert features specifically aimed at behavior change should instead be handled more explicitly within the existing Trip Updates / Trip Modifications spec.