Add new SPECIAL_EVENT Cause to GTFS-realtime Service Alerts

[ckraatz]

Describe the problem

Many producers find it difficult to select a Cause from the current list in certain common situations, and we've heard complaints from customers about this.

I'm proposing to add SPECIAL_EVENT to address this. Capturing alert causes also provides more structured data, which could be used to display Alerts in certain ways on agency websites and potentially in apps.

Use cases

SPECIAL_EVENT would be the appropriate Cause to select in the following common scenarios faced by many agencies:

• Parades and festivals
• Marathons, walks and runs that shut down streets
• Concerts and other performances
• Farmers markets

Proposed solution

Add SPECIAL_EVENT to the Cause list as option 13 as follows:

// Cause of this alert. If cause_detail is included, then Cause must also be included.
enum Cause {
UNKNOWN_CAUSE = 1;
OTHER_CAUSE = 2; // Not machine-representable.
TECHNICAL_PROBLEM = 3;
STRIKE = 4; // Public transit agency employees stopped working.
DEMONSTRATION = 5; // People are blocking the streets.
ACCIDENT = 6;
HOLIDAY = 7;
WEATHER = 8;
MAINTENANCE = 9;
CONSTRUCTION = 10;
POLICE_ACTIVITY = 11;
MEDICAL_EMERGENCY = 12;
SPECIAL_EVENT = 13; // A special one-time or recurring event such as a parade, festival, performance, farmers market, or sporting event.
}

Additional information

There has been some discussion about this in the MobilityData Slack. @stevenmwhite @jfabi @doconnoronca and Logan Nash have chimed in, and it seems consensus for this change.

@gcamp and @bdferris-v2 could you please weigh in from Transit and Google's standpoint? How do you use Cause values currently, if at all?

I look forward to hearing any feedback about this idea, particularly in the following areas:

• What other use cases do you see for this new Cause?
• Are there other Cause values we could add/revise (as minimally as possible) such that this list encompasses at least 90% of the most common actual scenarios, and at least 90% of the most common scenarios currently leading to use of Other_Cause?
• Are there any unintended consequences for apps, websites or other Alerts consumers?

[gcamp]

We use the cause values but minimally. It will change some fallback values when other fields are not present (like the description), and will allow us to provide a more detailed summary (before the user seeks the full alert content).

I see no problem with the proposal and support it. 👍

[stevenmwhite]

We've had a few agency customers ask us to add this to the list of causes we offer in our software, not understanding that the causes are defined by a specification and not just product features we unilaterally decide.

This is the one and only new cause we've ever had requests for, and we've had it multiple times from different agencies. It's the one major hole I see in the current list and I'm in favor of adding it.

[hbruch]

We enhance agencies' gtfs-rt alert feeds and add causes derived from descriptions. We do this to allow clients to display e.g. symbols representing the alert type or give better summaries.

Concerts and events (e.g. sports events like football games) have been categories we until now explicitly assigned to OTHER_CAUSE. SPECAL_EVENT would indeed be a good addition and cover > 90% of the OTHER_CAUSE.

Regarding the question "other use cases for the new category", I suggest to broaden "marathon" to sports events, or add "or other sports events". Such events may result in positive effects like additional services,

Less than 10% of our category "OTHER_CAUSE" are short term staff shortages or natural disasters (some of the latter we assign to WEATHER).

[laurentg]

Many of our users expressed this lack as well in the list of causes, and many current uses of OTHER_CAUSE are indeed "special events" of the described types.

[ckraatz]

I suggest to broaden "marathon" to sports events, or add "or other sports events". Such events may result in positive effects like additional services,

@hbruch great feedback, thanks! I changed the guidance in the proposed change from “marathon” to “sporting event.”

I appreciate your validation based on analyzing the text strings. That’s exactly how I figured we’d have to empirically validate that 90% goal, and I’m glad you already did it!

[leonardehrenfried]

I like this proposal and will vote in favour.

[ckraatz]

@etienne0101 how can I turn this into a Pull Request? Do I need push access granted for the google/transit repo so I can create a new branch with these changes?

[ckraatz]

I created a Pull Request that, as far as I understand the process, is now open for voting. Please vote! #577

[ckraatz]

Operational (vehicle, personal) and weather related are obviously in the top 3

@skinkie I wanted to move this discussion from the Pull Request to the Issue. You listed categories of causes (which I think speaks to the validity of Cause being a list of categories). I was asking about usage of specific Siri causes. Do you have any data about that? If, for example, the top 3-10 are actually the more general Siri causes that would be interesting.

@hbruch do you have any data about Siri cause usage stats?

[ckraatz]

I can't tag @felixguendling for some reason, but wanted to bring him into the Issue discussion too. He advocated for adopting a very big list of causes and software deciding which should be available in each region. He noted there are a lot of bomb disposals in Germany and he thinks that should be represented in the Cause field. It's certainly covered by POLICE_ACTIVITY (which is itself also a Siri cause).

There are two competing directions here that I'll have to think about further:

1. Have a single list (100+) of specific causes/reasons/categories, and narrow down which are most relevant in each agency's UI for usability
2. Have a small list of categories (10ish) and use a second field to define more specific causes (with two sub-options: standardized or customized specific causes)