Add NO_EFFECT effect option for GTFS-realtime service alert

[barbeau]

• Some transit agencies are publishing service alerts that don't actually impact the transit network. Examples include reminding riders of upcoming holiday schedules, advertising public meetings, and soliciting feedback via surveys (see below examples from HART's feed in Tampa, FL). EDIT - Per discussion in this thread, upcoming holidays should be marked MODIFIED_SERVICE

• This proposal adds a new alert Effect enumeration NO_EFFECT so that transit agency can clearly label these types of alerts as not impacting the transit network. Consumers can then make a choice if they want to surface these types of alerts in their UI.

Announced on the gtfs-realtime Google Group at https://groups.google.com/forum/#!topic/gtfs-realtime/AxHtb6qjKtE.

[abyrd]

Seems reasonable to me. One could argue that the information in the second image example (holiday schedule) does impact the network, but it's true that it doesn't necessarily mean there are any changes to the schedule as published in the GTFS.

[paulswartz]

I agree with @abyrd on both counts.

1. +1 to adding this
2. The second screenshot seems more like MODIFIED_SERVICE to me.

[barbeau]

Thanks @abyrd and @paulswartz for the comments! Yes, the 2nd alert is interesting and raises some questions as to whether the alert has the Effect of MODIFIED_SERVICE or NO_EFFECT. From a riders perspective, it's MODIFIED_SERVICE (when compared to the normal schedule on that day of the week), but from a GTFS consumer's perspective, it's NO_EFFECT because this schedule is already reflected in the GTFS data.

Given that these enums aren't directly rider-facing and are consumed by GTFS-consuming apps first, I'd err on the side of NO_EFFECT, because the app doesn't need to take any action based on the alert (or any other data source) and the schedule would still be correctly shown to the rider the following day.

[jeffkessler-keolis]

+1

[LeoFrachet]

My first thought would have been to let EFFECT empty and define the alert as SEVERITY=INFO. But I see why you could find cleaner to have a value for EFFECT. So LGTM.

[skinkie]

Why not NO_EFFECT = 0?

[barbeau]

Why not NO_EFFECT = 0?

@skinkie Because the smallest field number you can specify is 1 - https://developers.google.com/protocol-buffers/docs/proto#assigning-field-numbers

[abyrd]

In light of the above discussion perhaps we should change this text: "The alert provides information to riders but does not affect operations" to make it more clear that it's not about whether operations are affected by what is described in the alert, but whether they are changed relative to the base static GTFS.

[paulswartz]

In light of the above discussion perhaps we should change this text: "The alert provides information to riders but does not affect operations" to make it more clear that it's not about whether operations are affected by what is described in the alert, but whether they are changed relative to the base static GTFS.

For other effect types, is the expectation that they're changed relative to GTFS? That's not how we used them. For example, we try to include replacement shuttle buses in GTFS where possible, and use DETOUR as the effect. The DETOUR is from what the riders expect as service, not what we're providing them in GTFS.

[barbeau]

@paulswartz Hmmm, good point. I believe Tampa has DETOUR alerts that are already reflected in GTFS too.

What do others think about classifying a reminder alert for a holiday schedule as MODIFIED_SERVICE instead of NO_EFFECT?

[abyrd]

Yes, good point @paulswartz. There has been some discussion about this in the past on the RT consuming end, for trip planner applications. Specifically: should alerts cause changes to the network by themselves (e.g. if they indicate a station closure). The conclusion was that no, the alerts should just be displayed as a warning to riders that something was "different than normal". So it makes sense to interpret the effect field of alerts relative to rider expectations, not GTFS content, as you said. Any modifications relative to GTFS content would have to be in other message types than Alerts to actually trigger a change in routing behavior.

This is something that should definitely be clarified in the spec or guidance materials though.

[skinkie]

@abyrd I would like to add that Google at this moment is pushing producers of which they receive vehiclePositions to use serviceAlerts to trigger changes in routing behavior.

[abyrd]

@skinkie do you know of any document about how this works? What is your opinion on this - should Alerts be only displayed, or modify routing?

[skinkie]

@abyrd in my humble opinion in the current GTFS-RT where tripUpdates materialise to an expanded schedule: hell no. But for some reason people always think they can make better predictions with worse than source data.

When serviceAlerts are communicating causes and effects with respect to a transport object, one could argue this is some form of SIRI-Situation eXchange. Without integration of such modifications, the information can only be applied on a journey advise after the routing, opposed to provide updated timetables for integrated with routing.

[abyrd]

@skinkie by "current GTFS-RT where tripUpdates materialise to an expanded schedule" are you referring to what we often call "propagation" (the fact that missing information in the tripUpdate is guessed by the consumer)?

By "integration of such modifications" do you mean inclusion of entire/complete updated schedules in TripUpdates (with no propagation / guesswork)?

So if I understand you right, you mean that unless TripUpdates are completely unambiguous and require no guesswork on the consumer, it would be near impossible to properly superimpose another layer of routing modifications based on Alerts?

I wouldn't say GTFS-RT is a sort of (a kind of) SIRI SX, because that's conflating the SIRI data standard with its purpose. But I'd say GTFS-RT alerts could serve a similar purpose to SIRI SX, and it might be useful in the long term for the GTFS-RT community to align the meaning and effects of GTFS-RT Alerts with those of SIRI-SX.

[skinkie]

@skinkie by "current GTFS-RT where tripUpdates materialise to an expanded schedule" are you referring to what we often call "propagation" (the fact that missing information in the tripUpdate is guessed by the consumer)?

Yes, where the good practise being a producer already provides it.

By "integration of such modifications" do you mean inclusion of entire/complete updated schedules in TripUpdates (with no propagation / guesswork)?

Actually I mean the integration of effects into a complete update schedule.

So if I understand you right, you mean that unless TripUpdates are completely unambiguous and require no guesswork on the consumer, it would be near impossible to properly superimpose another layer of routing modifications based on Alerts?

It is fully possible, with the proper business rules, but it is a completely different scope. Is this what a consumer should implement? Or what you could ask a producer to build when doing a tender?

[barbeau]

Google's documentation on Alert Effects is at the bottom of this page:
https://support.google.com/transitpartners/answer/6374472?hl=en&ref_topic=6159819

...and guidelines for "How to cancel a trip":
https://support.google.com/transitpartners/answer/6325970?hl=en&ref_topic=6159819

...and "Realtime information in routing results":
https://support.google.com/transitpartners/answer/6327328?hl=en&ref_topic=6159819

Based on this documentation, and to my knowledge, currently the only Alert Effect that changes the network (i.e., is more than just a rider-facing informational message) is NO_SERVICE, which cancels trips when a trip_id is referenced, cancels the route when the route_id is referenced, and closes stops when a stop_id is referenced.

The top link says:

NO_SERVICE: There’s no service on the line or at certain stops, or a specific trip has been canceled. This will trigger Trip Planner to re-route users around the disruption.

All other Alerts with other Effects will just be shown to the rider, but won't affect trip plan results or real-time info shown to riders.

[barbeau]

@paulswartz @abyrd @skinkie I just updated this proposal and moved the example of upcoming holiday schedule from NO_EFFECT to MODIFIED_SERVICE in 14544a5.

[gcamp]

Shouldn't there be a concept to differentiate a planned MODIFIED_SERVICE and unplanned or unexpected MODIFIED_SERVICE?

[ibi-group-team]

We have come across similar use cases for NO_EFFECT and support this. One thought: what about naming it INFORMATIONAL instead of NO_EFFECT? We're not necessarily opposed to NO_EFFECT, but when thinking about effects as how they impact passengers, most/all alerts will effect passengers somehow, so INFORMATIONAL may be more accurate than NO_EFFECT.

[barbeau]

@gcamp said:

Shouldn't there be a concept to differentiate a planned MODIFIED_SERVICE and unplanned or unexpected MODIFIED_SERVICE?

That makes sense to me, although IMO that's outside the scope of this proposal. As @abyrd mentioned earlier we need to clarify in the spec whether alerts are intended to alter the network and affect trip plans, and I see this being part of that discussion.

@ibi-group-team said:

One thought: what about naming it INFORMATIONAL instead of NO_EFFECT? We're not necessarily opposed to NO_EFFECT, but when thinking about effects as how they impact passengers, most/all alerts will effect passengers somehow, so INFORMATIONAL may be more accurate than NO_EFFECT.

I'd prefer to stick with NO_EFFECT to be a clear negation of the Effect field. I think naming it INFORMATIONAL would conflate Effect and the new Severity field. The two examples I currently have for NO_EFFECT are "advertising public meetings and soliciting feedback via surveys", which really don't affect operations, which is our definition - "The alert provides information to riders but does not affect operations".

[barbeau]

This pull request has been open for more than one week, so per the Official Process I'm calling for a vote.

Vote will be closed on Tuesday February 5th at 23:59:59 UTC.

[ghost]

+1

[skinkie]

0. I am not against adding this. But I would feel that not providing the EFFECT should imply this.

[devinbraun]

+1 - definitely need this type of clarification. System-wide alerts for informational purposes only are important so they can be filtered out or shown in a different way without affecting how transit service is shown to the user.

[paulswartz]

+1

[gcamp]

Also 0. I agree on the principle but I'm not 100% sure of the implementation, but I don't have better ways to implement this.

[abyrd]

+1

@skinkie a missing value can indicate that the producer just doesn't know or doesn't bother providing an effect. Explicitly stating NO_EFFECT reassures you that the producer is intentionally providing the value rather than just providing incomplete data (essentially, FALSE instead of NULL in a database field).

@gcamp can you clarify what you hesitate about in the implementation? Do I understand correctly that you think there should be a way to indicate the alert has no direct impact on operations, but you are hesitant about this being one of the enum values for Alert.Effect?

[gcamp]

@abyrd It's mainly naming, I don't feed NO_EFFECT represents accurately the concept represented here, but as I said I don't have anything better to propose. I agree that there should be an effect for these alerts however.

[barbeau]

Voting is closed on this proposal and the results are:

• Yes - 4
• Abstain - 2

So it passes! Thanks all!