Clarify spec: Add definitions to Cause and Effect values and clarify Trip Update and Service Alerts usage for consumer routing decisions #648
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -386,41 +386,41 @@ Cause of this alert. | |||||
|
|
||||||
| **Values** | ||||||
|
|
||||||
| | _**Value**_ | _**Comment**_ | | ||||||
| |-------------|----------------| | ||||||
| | **UNKNOWN_CAUSE** | Used when the cause of the disruption is not known or has not been determined. Should be avoided if any more specific cause can be reasonably identified. | | ||||||
| | **OTHER_CAUSE** | Used for causes that do not represented by any of predefined options. | | ||||||
| | **TECHNICAL_PROBLEM** | Issues related to vehicles or infrastructure malfunctioning. Examples include mechanical failure and information system bugs. | | ||||||
| | **STRIKE** | Service disruptions caused by a labor strike involving the transit agency or operator. | | ||||||
| | **DEMONSTRATION** | Service disruptions caused by public demonstration, protest, or gathering. | | ||||||
| | **ACCIDENT** | Incidents such as collisions or derailments that disrupt services. | | ||||||
| | **HOLIDAY** | Any public holiday that might result in a change of service. | | ||||||
| | **WEATHER** | Disruptions caused by weather conditions such as snow, storms, flooding, etc. | | ||||||
| | **MAINTENANCE** | Planned maintenance related to the services. Examples include track maintenance, elevator maintenance and vehicle maintenance. | | ||||||
| | **CONSTRUCTION** | Any construction that affects the service, regardless whether it relates to the services or not. Examples include station construction and roadworks that affect bus routes. | | ||||||
| | **POLICE_ACTIVITY** | Disruptions due to law enforcement activity or security incidents. Examples include investigations or security threats. | | ||||||
| | **MEDICAL_EMERGENCY** | Incidents involving passenger or staff medical emergencies. Examples include an on-board medical problem that forces a train to stop. | | ||||||
| | **SPECIAL_EVENT** | A special one-time or recurring event such as a parade, festival, performance, farmers market, or sporting event. | | ||||||
|
|
||||||
| ## _enum_ Effect | ||||||
|
|
||||||
| The effect of this problem on the affected entity. | ||||||
|
|
||||||
| **Values** | ||||||
|
|
||||||
| | _**Value**_ | _**Comment**_ | | ||||||
| |-------------|----------------| | ||||||
| | **NO_SERVICE** | No transit service to the specified entity(-ies).<br>- For stations or stops, the rider will not be able to board or alight.<br>- For routes, the route will not run.<br>- For trips, those specific trips are cancelled. | | ||||||
|
Contributor
There was a problem hiding this comment. Was leaving out station entrances and pathway nodes done on purpose?
Collaborator
Author
There was a problem hiding this comment. @gcamp yes. The topic of allowing alerts for pathways, entrances, exits is something that has been talked about for a while and we are planning to start that conversation soon. Building one what was mentioned on issue#268, the intent was to clarify some things in the realtime spec (such as here and in #546 ), create documentation to help with implementation and how to deal with use-cases (such as the spec vs RT Guidance and the RT Alerts Guidance), then eventually get to "alerts on pathway data". That conversation can involve all |
||||||
| | **REDUCED_SERVICE** | The number or frequency of trips is reduced. | | ||||||
| | **SIGNIFICANT_DELAYS** | The route will consistently run late (insignificant delays should only be provided through [Trip updates](trip-updates.md)). | | ||||||
| | **DETOUR** | The route changes its shape, resulting in the route not serving one or multiple stops, or picking up/dropping off at other locations. | | ||||||
|
Contributor
There was a problem hiding this comment.
Suggested change
Detour doesn't mean stops are cancelled
Collaborator
Author
There was a problem hiding this comment. There was a previous comment from @ckraatz mentioning that if a detour does not change the behaviour at any stop, then it does not matter to the rider. And that can be communicated via a SIGNIFICANT_DELAYS alert. I like @gcamp's wording, but would like to discuss whether the DETOUR alert "may affect" or "will affect" pickup/drop off at some stops. One case I see for keeping "may" and including detours that only change the shape is in Montreal; where STM buses can drop people off at night between stops if they are traveling alone or with a child, for safety reasons. If a detour were to change the shape but keep the same behaviour at the stops, it would be valuable to communicate the disruption as a DETOUR alert to let people know that the itinerary changed and that their "between-stops" drop-off might not be done.
Contributor
There was a problem hiding this comment. If we want to make a detour that doesn't affect stop SIGNIFICANT_DELAYS, that's probably ok, but we should be explicit in the spec. I think in most people's mind a detour is a detour, affecting stops or not. What you're referencing for the STM is more akin a deviated service than a detour. There was a problem hiding this comment. I would agree here that the use of the DETOUR status alone should not mean stops are cancelled. Perhaps language should be added here which states: "The route changes its shape. Routing must only be affected if TripModifications are also provided which detail the new shape of the route and any removed or replaced stops." |
||||||
| | **ADDITIONAL_SERVICE** | The number or frequency of trips is increased. For example, more buses are running to cover for a special event. | | ||||||
| | **MODIFIED_SERVICE** | Operations are different from what the rider would normally expect. An example is an alert that reminds riders of an upcoming holiday schedule that is different from normal service on that day of the week. | | ||||||
| | **OTHER_EFFECT** | Not represented by any of these options. | | ||||||
| | **UNKNOWN_EFFECT** | Used for alerts whose effect has not been identified yet. Do not use "Unknown effect" if the effect of the alert is known or can be deduced from the alert header or description. | | ||||||
| | **STOP_MOVED** | A stop location is changed temporarily or permanently (if known to be permanent, ensure the new location is reflected in the schedule data). | | ||||||
| | **NO_EFFECT** | The alert provides information to riders but does not affect operations. Examples include advertising public meetings and soliciting feedback via surveys. Unless necessary, it is advised not to use this effect. | | ||||||
| | **ACCESSIBILITY_ISSUE** | The alert provides information about accessibility issues that affect step-free access. Examples include an out of service elevator or movable ramps, a bus that is unable to kneel, or an exceptional service with trains that have a big platform gap. | | ||||||
|
|
||||||
| ## _enum_ SeverityLevel | ||||||
|
|
||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this sentence very hard to parse. Could you perhaps re-write it for maximum clarity (perhaps at the cost of some verbosity)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The discussion was something like: some producers are unable to make new timetables. For months they are using their AVL system to skip a stop. But their AVL system has a horizon of just 90 minutes. Hence every trip planned after 90 minutes would still show the regular timetable.
For me it is also very hard to comprehend why people would accept this quality of their vendors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to design the GTFS standard for the worst practices? I would rather design for good practices to produce great results.
In case they really can't produce a static GTFS file for months, I would rather write a little script that takes the GTFS file and the GTFS-RT protobuf and update the GTFS file accordingly. In most systems data coming in via GTFS-static will also be displayed differently than GTFS-RT and in this case you would probably want the GTFS-static version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll start by saying that yes, I agree that the standard should be built for good practices and not cater to bad vendor behavior. I also understand where you're coming from that in principle GTFS static should be updated in cases of known route changes. However, I just want to offer a slightly different framing with what this actually looks like IRL rather than just in digital.
In the physical world, an agency may post a temporary sign on a bus stop that says a route will be diverted away from this stop for an amount of time due to construction. The bus stop sign itself still remains and lists that route as stopping there, since it will eventually return after the disruption is over.
The digital equivalent of updating GTFS static in this scenario is more like removing the bus stop sign entirely until the disruption is over. There hasn't been an official service "change" per say, just a temporary adjustment. Basically, by updating GTFS static there's no definitive way to link the change to a "why" without the service alert.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this shortcoming of GTFS static will be solved by #638 (no boarding + no alighting + notice)