Clarification of CANCELED/SKIPPED TripUpdates VS NO_SERVICE Alerts #482
Conversation
isabelle-dr
added
Change: Clarification
|
-1 Alerts should never be the source of truth considering there are tripUpdates available. Alerts are informative. |
|
Didn't we just approve Trip Modifications to handle long term service changes? I'm not sure we should be added a third way to describe service changes. |
|
We do use NO_SERVICE alerts (only alerts with that effect) to modify trip planner. It is hard to use trip updates for stop, route or agency closures for a trip far in the future. That will just blow up the size of trip updates feed and put unbearable load on both providers and consumers. |
|
@skinkie I believe the intention in this PR may not have been entirely clear. Let me try to clarify it.
Maybe I should specify what I mean by "source of truth" here. If I want to communicate that an entire line is closed for say 2h, there are two options:
If 1 and 2 are present, or if only 1 is present, we can reasonably assume the line is closed. However, if 2 is present without 1, we should treat Alerts as the source of truth and assume the line is closed for 2 hours, even without TripUpdates. The same would apply to trips, route types, or stops.
The proposal here is to recommend using Alerts rather than TripUpdates (not Alerts rather than modifying the GTFS Schedule), for the efficiency reasons mentioned by @IvanVolosyuk here and by @gcamp in this comment.
Here I am only referring to Alerts with Effect.NO_SERVICE. I have modified the PR to make this clearer. Does this change your point of view? |
|
@doconnoronca I am not super familiar with Trip Modifications, curious to have thoughts from @gcamp here. We could potentially update the statement to:
|
|
@isabelle-dr Thanks for this clarification. But I remain against this proposal. |
|
@skinkie Can you provide more details on the particular elements you're against? Also, would you have an alternative solution for the issues mentioned, or would you prefer to leave the spec open on these topics? |
|
Introducing alerts that modify journey planner behaviour (routing) requires the journey planner (or consuming system) to integrate data, rather than applying data. Applying happens for tripUpdates (on the timetable), but also for alerts (on the presentation level). This is a strict distinction I would like to keep. Mainly because the aim for GTFS(-RT) was provide travel information, and not be an interface between (naive) CAD/AVL systems. I am also aware that Google Transit thinks they can do better predictions using vehiclePositions, that does not mean they can (hint: heavy rail). If the end-goal is to be able to do vehiclePositions + NO_SERVICE, this is for me a step in the wrong direction. |
|
I'm actually ok not using alert for change of behaviour but there must be a way to define longer term changes. It's true trip modifications is a good start (it doesn't do everything like closing the entire line). |
|
It's not clear to me that TripModifications will naturally extend to concisely indicating that a particular stop, route, or agency is out of service, at least without significant retooling. And I think the end result would end up looking a lot like the Alert data structure we have today. @skinkie I think your notion that GTFS only exists to provide traveller information as direct presentation of data without deeper integration would imply that we should not build trip planners on top of GTFS at all? Routing is the deepest integration of data there is. By extension, I think it's reasonable for consuming apps to do more than blindly pass on data as presentation-only for GTFS-RT as well. |
I am not against that alerts are used as alerts, I am against that it affect routing. If something is out of service (long term) it should not appear in GTFS, if it is out of service during the day I expect it to be in tripUpdates. |
|
The GTFS Reference mentions explicitly at what point should the changes be communicated via GTFS-RT rather than the static feed (source):
If we pause on the "can Alerts be used to modify routing or not" portion of this PR and look at the two other items included here, is one of them (or both) a helpful addition in GTFS Realtime?
Or should we be looking into adding new functionalities to GTFS Realtime to share that networks/routes/stops are out of service affecting multiple trips, and within these 7 days where GTFS Realtime should be used? |
We are already in progres with extending tripUpdates. I think what my aim would be: Alert with Effect.NO_SERVICE must be reflected as CANCELED, SKIPPED in tripUpdates. An Alert alone is not enough to change routing behavior. |
I agree with that
I agree that's a completely reasonable interpretation. I think the biggest problem with having alert changing behaviour is the expectation that's not clear for producers. For example, even if an agency uses How do we fix that? Adding details in the specification of the expected effect of an alert will certainly make the situation way better but I'm not sure it's going to fix the base fact that the field is name |
You are really understanding this issue (and my concerns) to the full. Because agencies want to inform people ahead of time, that is why I think an alert is something different.
Could we push this discussion maybe in a direction where TripDescriptor would allow more broad selections? |
|
I tend to agree with @skinkie's comments here. Alerts are intended for informational purposes. Allowing a consumer to interpret an Alert as a routing change risks services being represented in ways the producer did not intend. This also increases the potential for inconsistent service information between consuming systems—what if one app decides to adjust routing based on the Alert, but another does not? Speaking as someone who uses multiple trip planning apps at once, this would be a frustrating user experience. The use case of an agency wanting to warn riders about upcoming changes is a perfect illustration of why I'd like to keep Alerts as a separate, information-only feature agnostic to routing changes. The active_period representing the time the alert is active and not the effect referenced in the alert follows the realtime spec to a T ("Time when the alert should be shown to the user."). Interpreting the spec as-written allows the Alert feature to retain the ambiguity necessarily present in certain "realtime" situations. Sometimes an agency may need to post an alert casting a wider, informational net while retaining the ability to make surgical changes affecting routing on a more granular level. One last use-case is when an agency posts an alert on an entity not directly affected because it is pertinent information to a user only exposed to the entity adjacent to the affected one in the trip planner results. For example, if the user is looking at a single route but there is an unexpected cancellation for a nearby stop that is a common transfer point for that route, there's a high possibility that rider is expecting to take that transfer, so it would be helpful for the agency to include an alert for the destination stop of the first leg even though that specific stop is technically unaffected.
I don't think I'd be on board with this statement as written, since it implies agencies must support TripUpdates if they are implementing Alerts. Perhaps a statement like "for routing behavior to reflect changes described in an Alert with Effect.NO_SERVICE, the change must be represented in TripUpdates as CANCELED or SKIPPED."...? |
Yes, Trip Modifications don't have to specify replacement stops (in fact I've never seen a live feed where it has). Trip Modification could be updated to add elements to allow it to cover all trips for a route or a route direction for the listed dates without having to list every trip. A feature indicating the trips are entirely cancelled (or replaced?) could also be added. |
|
The issue with cancellations, that last for days or weeks, could often be solved by allowing planned cancellations in the static data. |
|
(Disclaimer: I am speaking only for myself here, as an interested party in the transit data space and a transit rider, not on behalf of my employer.) As a transit rider and a user of some of the apps mentioned in this issue, I have personally seen this backfire. I suspect the risk is more acute where GTFS-rt service alerts are being generated from a source that does not natively implement the GTFS-rt Alert data model (i.e. being translated, either mechanically or by hand from a non-GTFS-rt source, either by the consumer or a third-party data broker), but either way the risk of publishing a service alert at the line (or broader) level with the Now, I understand it's easy to push back on that, and shift the burden to producers: "well, agencies should be more careful about the alerts they generate!". And yes, it's reasonable to expect that a producer generating an alert with the As a concrete example, last year I rode the rabbittransit 83S from York, PA to Hunt Valley, MD. At the time, there was a single stop out of service, with an alert published to that effect. Even though this alert only affected a single stop, it was tagged at the line level - perhaps to increase visibility, as some consumers surface stop-level alerts poorly (or in hard-to-find ways)? This had the consequence of causing the consuming app I was using to conclude that the entire 83S route was out of service, even though there were buses running on the route (and, as I recall from the time, appearing in AVL data!). Had I not known what was going on I might have had a seriously adverse experience.
(in case anyone has their doubts, yes, the bus really did run, and here it is at the Hunt Valley Light Rail stop...)
I don't deny that there is a legitimate need here. But rather than drawing inferences from an Alert feed, the solution probably lies around some combination of scheduled cancellations in static GTFS, GTFS-ServiceChanges, GTFS-TripModifications, and so on. There is also a need for improvements on the producer side - clearly asking an operator to select every affected trip one-by-one is not viable. Producer-side tools need to support symbolic statements like "trips on route X, with headsign Z, between dates A and B" and then allow users to operate on those trips en bloc, even if the realization in GTFS or GTFS-rt is an expanded list of trip IDs. |
|
It is challenging, that cancelation of a trip, closure of a stop etc could be expressed in two potentially contradicting ways. That a single service alert can impact a significant number of services over a longer period into the future than a trip_updates feed typically covers is a strength and a weakness. We've seen plenty of examples of agencies publish alerts that should relate to specific lines but which are scoped to affect the entire agency. In the UK we often see the responsibility for communicating information about disruptions falls to the local authority, in many cases the smaller commercial operators do not have the systems or staff in place to publish this information themselves. |
|
I acknowledge the concerns raised here that data producers may be producing overly broad alerts that can have unintended impacts on routing when NO_SERVICE is specified without a full understanding of the implications (or perhaps they just made a mistake during data entry). That said, I'm not convinced that some new specification will be automatically free of those same issues. But I think the high-level approach is the same either way: better tooling and better documentation in the spec itself. To be frank, Google has had its existing NO_SERVICE behavior for long enough that we'd be reluctant to just turn it off. Even if we agreed on a new spec for cancellations today, it will take years for tooling and data producers to catch up (witness the slow adoption of alert tooling in the first place). Thus, we will be in a world of supporting the old thing and the new thing for quite a while. That isn't necessarily an argument that we shouldn't try to do something new here (or never try anything new), but I want to be realistic about the timeframe. For many producers, alerts will be their best path to specifying short-term cancellations at the agency, line, or stop level, probably for years to come. Given that, I'm still in favor of clarifying the spec around behavior and best practices where we can. |
isabelle-dr
added
the
Status: Discussion
isabelle-dr
added
the
Change: Best Practice
|
I'm in the camp of using Alerts as the source of truth for reflecting route/trip/stop impacts in realtime even if they conflict with the TripUpdate feed. That's how we've been doing this for the last almost seven years and it makes sense to us for one simple reason- We have full control over our Alert feed. Swiftly is our agency of record for producing our TripUpdate feed and incorporating detours we draw in their app and detours from TransitMaster/OnRoute that we push to them as Service Adjustments via their API's. We don't control our TripUpdate feed and I'm guessing most agencies don't. It's complicated and there simply aren't a whole lot of tools to produce a really good TripUpdate feed for most agencies to use in-house. Not to mention the difficulty of pulling operational changes out of the CAD/AVL to put into a TripUpdate feed, especially one managed by a 3rd party. On top of that, because of the complexity of TripUpdates, there is a noticeable disparity amongst GTFS-RT producers and consumers in what is supported or what may be supported in the future. Case in point, DELETED trips from two years ago which is still lacking support even though agencies like us are ready to use it. Our Trapeze setup doesn't even support features that Swiftly's TripUpdate feed does let alone the latest and greatest. Service Alerts are a different matter. They're informative as has been said here. But more importantly, they're simple and I think far easier for an agency to put together than a fully fleshed out TripUpdate feed with all the latest bells and whistles. Us folks at the Maryland Transit Administration have been leveraging Transit's ability to see it as the source of truth for over six years before Swiftly had the ability to support detours and stop closures and the like within their dashboard. Using Plus by allowing Alerts to be separate and a source of truth, you keep GTFS-RT modularity by not requiring GTFS-RT producers to also ingest Alerts or, worse, force agencies to use their Service Alert product. We love Swiftly, but don't use their Service Alert module since we built a system in-house and, more importantly, Swiftly won't ingest our Service Alert feed meaning they couldn't reflect our changes in the TripUpdate feed they produce for us even if we wanted them to. That's what those Service Adjustment API's are for so we can get them that info without them ingesting it. Trip Modifications I think works well for short term disruptions but not a multi-day/week/month impact. Modifying the GTFS to deploy schedule changes within 24 hours is viable except consumers may not be able to handle the frequency of those updates. In a perfect world full of equilibrium amongst producers and consumers where spec changes were implemented in weeks instead of months or years across all parties, I would agree with @skinkie. But given the reality we face in the transit industry and the arms race that is getting data to customers in the quickest and most accurate fashion, us folks in Maryland are on the side of KISS. Though like @gcamp said, if there are better ideas to extending the spec, we're not opposed to that either. |
|
Thinking out loud. Is there an opportunity to add a field to the alert feed and stating that the alert is authoritative for cancellations? My personal preference would still not to allow two ways to do the same thing. |
In a perfect world it should, but that's why stuff like the Transit App's detour detection functionality is coming into existence because the world is far from perfect.ctive, buses should be told to pick up riders at stops that may be "closed" for some disruption if it is safe to do but has not been updated in the RT feeds at that exact moment. You seem to be implying that if the RT feeds say it isn't being served then the on-the-street operations should obey that, which simply isn't how this works.
So if I am writing a journey planner, and I receive a NO_SERVICE Alert at a stop and StopTimeUpdates for those stops showing real ETDs, should I route my customers to board the bus at that stop? |
For us, the trip planner would not route customers to that stop for that bus. However, if they were at the stop and the bus came through and stopped there and opened the door to pick folks up, one would hope they would board or at the very least ask if the operator was running even if the app says they aren't. Again, that's an agency communication limitation and it's on us agencies to improve that while the expectation for trip planner would be to convey what we as an agency communicate to them. Until we get fully interconnected public/private communication systems that allows us to know the moment any disruption that we have no control over (weather, police, fire, construction, etc) is complete, we will continue to communicate what we are aware of and expect a consumer to reflect that. And in this case, because of limits on some RT feed producers not being able to produce Trip Modifications or other disruption events, or simply wanting to notify users of stop closures more than 7 days out while not being able to modify the static GTFS for , using the Alert NO_SERVICE setup has and would continue to achieve that. In our case, Baltimore City does not give us API access to permits for construction or any API for local police/fire departments to know when scenes have been cleared. In fact, our regional electric provider has been given carte blanche to setup closures anytime/anywhere without permits or notification to anyone in local or state government, Thus we rely on human communication in many cases which will always be slower than bits and bytes. Still curious how and @skinkie feel about NO_SERVICE impacting non-transit operation stuff like Pathways so we can get some elevator/escalator realtime routing working 😄 |
I'm curious how you define breaking change, because adding a functionality to the spec that might affect negatively consumers if producers start to use it is not a breaking change. We add multiple of in recent memory like the addition of I would still add the mention that producers SHOULD produce SKIPPED stop update when the close stops with alerts with I'd like to re-surface @skinkie's proposal to add a boolean to the alert to specify if the alert should have a change in behaviour for planning. Seems like the most common sense way to achieve what we're looking here. |
My personal preference is still to introduce a new kind of feed that takes control actions (in SIRI terms) and not mix it with alerts. In addition to this, I have been advocating in the past ten years to keep GTFS-RT stupid simple, hence not do things that require integration at the consumer. tripUpdates must be directly be consumable, and it should not be any issue to implement connection-scan-algorithm on top of it. Hence the work that Transit detours does, should happen inside the CAD/AVL. The work that Google Transit does and claiming it can do better predictions than the CAD/AVL, should be done in the CAD/AVL. Anything that would require consumers to outsmart both the producer and other consumers leads to unpredictable behavior. This is not a communication issue, purely system architecture. |
Adding a flag to the Alert entity is something we can work with. It's easy for us to implement, but not sure what impact it would have on other agencies using this functionality that is currently supported. If they can't update it due to vendor limitations or something similar, are they out of luck here? I don't know how prevalent NO_SERVICE modifications are in Transit, Google, Apple, etc or what percentage of agencies may have to change their setup as a result. The "backwards compatibility" component is my only worry with adding a flag for something that already works without it (even though it's not technically law it's how it's worked for years)😕
I agree, but again we're limited by what the producers offer and time/staff/money/legislative requirements. And since Swiftly, especially, is not a CAD/AVL provider, that adds extra complexity to the transit technology ecosystem. Hence hoping folks can see the reality of how things are and allowing agencies to use the best tools available to them without holding them back for months/years because the ideal state of the RT spec isn't being met 🙏 Transit's detected detours BTW don't go into the public GTFS-RT Trip Update feed. That's specific to their app setup. We're working to be able to export those to then import into Swiftly because Swiftly has some good API's to allow us to do that (which would then get it into the public GTFS-RT feed), but there are plenty of other producers and CAD/AVL systems where this situation will not work. Our CAD/AVL system through Trapeze might have detour detection functionality a few years from now.... or they might realize agencies forged on ahead without them because the market decided that's what was needed and Trapeze doesn't feel like they have to re-build a solution that agencies already have. They definitely will not have API's to allow for ingesting data from another providers anytime soon, though 😭 It's a veritable transit technology arms race and unless we start certifying producers/consumers to spec compliance, we're always going to have varying levels across the board IMO 🚀 🌔 |
Agreed with all of this with the exception that the "producers SHOULD produce SKIPPED stop update" should be qualified to say this should be done for only some reasonable amount of time into the future ("reasonable" would need to be some number of hours or perhaps days defined through discussion here).
Agreed with @SteveGladstone on this one. This is also something we could implement, but it's a problem that it would remove existing functionality until implemented by producers and consumers. It also would just shift from one field to another the problem noted earlier in this discussion about producers sometimes publishing alerts that affect a broader set of entites than actually affected. As an example, consider a stop closure alert published as affecting an entire route. This new boolean could be set to indicate this alert should not change trip planner behavior or that it is an information-only alert, but that would require the user entering this alert to set that boolean correctly. As noted earlier by @SteveGladstone, this same functionality could be achieved by using |
|
The boolean field can be documented the following way:
This way we are back to the square one. I don't think the field is binding, as the consumer is ingesting factual information about the disruption and is free to represent it to their users in a way it finds reasonable. |
|
Adding a boolean does seem like the best compromise for all parties. However, I would prefer to see the unspecified scenario default to routing=unchanged, otherwise we are codifying the ambiguity this proposal had initially been trying to resolve for the default behavior (since consumers would be able to interpret the alert however they want). How does one determine how a particular consumer will implement the effect? How does a producer handle multiple consumers implementing the same data differently? I would rather have a decisive rule that NO_SERVICE is the source of truth for routing (which I am not in favor of, generally). Would the following work?
Lastly—if you'll allow me what is perhaps a slight indulgence in melodrama—I'd like to mention the comment made earlier about opposition based on principle. Even if the opposition expressed here were solely a matter of principle, principle does matter when it comes to stewardship of a standard. We do not want to set decision-making precedents that risk being used to justify problematic changes down the road, even if it's a more convenient way of resolving a problem we're facing right now. Codifying the above ambiguity, for example, would set the precedent that opposite interpretations among different consumers are acceptable (i.e., some consumers interpret as informational only, some interpret as source of truth for routing behavior). I don't think this is a norm we want to establish. |
|
Well said, Weston. A standard should codify good practises and not be rubber stamping processes "in the wild". That said, I can live with the boolean but I would probably prefer something a bit more explicit like an "entity closure" feed. |
|
+2 to the two above. |
|
I'm not sure that adding the boolean such that a producer has to make this decision for each and every individual alert is really the best way to resolve ambiguity, and it only resolves part of the ambiguity. For context, at GMV we are a producer on behalf of our agency customers. Our goal is for agencies to not have to think about GTFS at all, and simply configure and operate the CAD/AVL system. GTFS is a technical data format for sharing info between computers, not something a specific person(s) at every agency of every size should have to think about. The best user experience for the agency staff who will create an alert is to simply write the alert, indicate its cause and effect (if known/applicable), and the dates the alert has an impact. This is where the spec's ambiguity and the user's expectations begin to collide. Most agency staff want to warn their riders of alert-worthy situations ahead of time if the situation is known in advance. But they also expect that if they made an alert saying a stop is closed, any reasonable app wouldn't route people to that stop. Because they don't know how every consumer treats the alert, they tend to make the date of the alert the date that they want to start communicating it, not necessarily the date that the impact begins. If a consumer uses this for routing or other display on a map, riders see an impact that is not actually in effect. If we give the producer the opportunity to determine whether routing should be applied... they could simply say no, don't make this impact routing. But does it impact map or other UI elements? What if they DO want routing to be applied (the street is closed and those stops are unavailable!), but also want to warn people days in advance? It's simply not clear or possible from the spec. If we're changing the spec here, I think it might be more advisable to include a new set of dates so that we have two distinct ranges to represent the |
I would agree with having more info is a nice to have, however like I've been saying the whole thread, I worry about implementation by producers and consumers, how long that will take to be viable, and the rider experience with such a change. All these field changes are not instantaneous and could break existing agency setups due to lag on producer/consumer implementation. Worse, it could cause inconsistent behavior. Say Transit implements it in 2 months but Google takes 6 months. That's a bad rider experience that is difficult to justify, especially since it's something that works as is right now. Plus, for communication vs impact time, this is already achievable by setting the EFFECT value to something more generic than NO_SERVICE. Doing that also keeps it more informational for riders because if we want to communicate an upcoming disruption, using OTHER_EFFECT as a catchall keeps it informational. Then the Alert gets updated with NO_SERVICE when route/stop cancellations occur.
Not melodrama at all! 😃 From my perspective when it comes to specifications and standards, principle is important. No argument there. However the problem here is that there is a lot of existing setups and there is no certification on a producer/consumer side that says what everyone supports. This creates a hurdle where consumers process TripUpdates but not TripModifications, or they implement CANCELED but not DELETED trips. Then you have producers having varying levels of spec support with changes costing $$$ and taking months to years to implement. This doesn't work when it comes to helping riders and improving the rider experience right now. That's why the path to least resistence on the agency/producer side is the path I almost always lean towards because concepts make sense even if specificity doesn't exist. If we decide that NO_SERVICE without other fields cannot impact trip planning per the specification, then we enter a lengthy timeframe when producers/consumers try to change the existing setup that Google, Apple, Transit, and others have in place. That will take time and, in the case of some agencies, not be feasible. And for those agencies without direct control over their RT feed production and have been using Alerts to modify routing in the big name apps, their riders are in for a rough time 😭 If this was something totally new that didn't exist in any capacity in the spec such as eliminating fares on service in realtime because the agency decides to have a surprise "fare free" afternoon or wants to offer free fares on certain routes to make up for disruptions, then going through this exercise to add more info and tweak the spec makes sense. Then again, I'd also argue that utilizing NO_SERVICE as a catchall implying that feed entity is not in use for the duration of the alert keeps things simple and covers a wide range of future options- such as Pathway impacts with closing stops/nodes. Shameless plug for another PR our agency has interest in because we're sitting on realtime Pathways updates via IoT and the spec currently doesn't support it... though it could easily if NO_SERVICE was allowed to be used 😬 Think of the riders! 😄 |
|
I'm not sure I understand the rush, @SteveGladstone. Don't you already have what you want, namely that Google and Transit process your information the way you want it? To me it seems better to have a spec that is well designed that people can move to in their own time while you can keep doing what you're doing. |
How NO_SERVICE could possibly work is holding back the ability of us and other agencies from implementing realtime Pathway updates via Alerts. The easiest way is that since Pathway nodes are in stops.txt, if a particular elevator or escalator or stairwell or something was inaccessible, that could be reflected easily through an Alert which is informative and impacts routing in a way that the TripUpdate feed doesn't support and could take a long time to support with the addition of extra specificity. With this lingering over the heads of consumers, getting realtime accessibility updates to riders in popular 3rd party platforms on a spec level isn't happening and, thus, riders who need that information and would love to have it in their trip planning platform of choice don't have it. Conceptually it makes sense and follows common practice that has existed over over five years at this point. Riders need this info and want this info, and waiting months or years for the spec and producers/consumers to catch up in the software lifecycle/government procurement timeline hurts 😭 There are folks here who still don't like TripModifications and would still be arguing for the spec to be different nearly a year on 😭 😭 If a boolean was approved tomorrow, we'd have it added by Monday in our feed. But then we wait for everyone to implement it which, as @bdferris-v2 hinted at, may take time and face resistance. Our implementation is possible because we control our Alerts producer and are able to use Swiftly's Service Adjustments API's to trigger SKIPPED stops in the TripUpdate feed. We're easily compliant. Plenty of other agencies like some of the locally operated transit systems here in Maryland don't have the time, staff, budget, technical knowhow, and/or flexibility to implement that kind of change. They rely on producers and I'm 100% certain our version of Trapeze will never support this change to Alerts. Nor do they (or we) have the ability in the Trapeze TripUpdate feed to modify the StopTimeUpdates to set SKIPPED values during these kinds of disruptions outside of OnRoute's Detours... which won't work with Transit app's detour detection functionality (ie, can't ingest Transit's detected detours into Trapeze). We exist to help people get where they need to go and they need to be empowered with the best possible information they can have as soon as they can have it. If we know, they should know and, conceptually, it aligns with practice that has existed for years. Hence why I'm trying to minimize changes because even though it might be a little more hassle for some consumers who purely want to utilize the TU feed, the reality is that all three feeds are necessary to truly convey the reality of the riders journey. You need the vehicle location, you need trip information, and you need to articulate disruptions now and into the future. Using NO_SERVICE as is for the major players has been that method; changing it would be more disruptive IMO. If a consumer providing routing and trip planning isn't consuming Alerts and doesn't want to consume Alerts to verify NO_SERVICE routing impacts, couldn't it also be said that they are free not to? Any trip planning consumer processing our data without also consuming our Alerts feed is already providing inferior data than those who do. Same with trip planning consumers who ignore our TripModifications in the TU feed. There is a balance between producers and consumers, but agencies/producers often have far less flexibility than consumers and the spec right now plus common practice just makes sense. Conceptual abstraction = maximum flexibility. I know we devs like specifics, but the ninja in me has to argue for and support the abstraction in the name of KISS and achieving the greatest possible outcome with the least amount of effort 😬 |
|
It seems a lot of the opposition here is due to consumers not wanting to be forced or required to have NO_SERVICE alerts impact trip plans, but the original proposal says “Alerts with Effect.NO_SERVICE can be used by consumers to modify trip planner behavior.” If anyone is opposed to this “can be used” statement, can you elaborate? As others have stated previously, there are already other cases of “consumers can choose what to support” in the spec. Regarding the proposed new boolean, this adds complexity, particularly for agency staff who create alerts, with no guarantee that it will remove all ambiguity as to whether an alert should impact routing. Besides the ambiguity around On the topic of As an example of a different interpretation, we (IBI Group, which is now Arcadis) have always interpreted Our interpretation was that consumers would display all alerts in the feed and use the This allows agencies to publish alerts before they begin while consumers can choose when and how to show the alert based on their use case. For example, a trip planner can show the alert only for trips that fall within the A few other examples: Transit has a similar interpretation, and Google says “active_period defines the time period that the alert is applied to the selectors”. I’ll be the first to admit our interpretation of |
|
My soft opposition is not due to the fact that it shouldn't be made easy to completely close stops (and other entities like pathways) which subsequently change routing behaviour. However, I would personally like to see a new feed message type that separates the "textual information" of the alerts from the destructive effects of a closure message. This can then be tailored to the needs of these actions (communication time, effect time). However, I know that change is hard and the actors slow to catch up. Therefore I would probably abstain. |
I would assume the boolean would be true or false in all cases, indicating they only use NO_SERVICE if there actually is no service for the stops, trips and period specified. I could even be in the feed header or, for agencies who can't upgrade their feed, it could be mentioned on the webpage where they provide their feeds. This appears to an example of what can go wrong by using all NO_SERVICE alerts to modify trip planner behaviour. |
That's a great example and likely (though I'm not in the mind of the agency that created that alert, I see this all the time from my agency customers) confusion over how consumers will display the alert. Agencies would like to show information to anyone who rides that route, so they make the alert apply to the entire route. In reality, the alert should apply just to the stop — but then it's up to the consumer who gets to see the alert and in what context. One app may only show it to someone who taps on the stop, another may show it to anyone planning a trip on the route, a third may show it to anyone viewing the region, for example. I believe that's part of the nature of this whole system, and that it's reasonable to let apps decide how and when to show information to their users (theoretically riders will migrate towards the more helpful apps, whatever they consider helpful), but the typical transit agency user who is creating an alert has a hard time limiting it to "just the raw data" and allowing the rider experience to be determined by the consuming apps. No matter what comes out of this discussion, it's likely that the tension between agencies wanting to control the experience vs. allowing consumers to control the experience will remain. |
I am opposed because it's not a statement of "feature support is optional" but that a certain interpretation of that feature is optional. If multiple interpretations are allowed, there needs to be a way for producers define and consumers to know which interpretation should be honored.
I personally don't think there is any ambiguity around how the definition is currently written. "Time when the alert should be shown to the user" means when the alert, which is intrinsically an informational feature, shall be displayed. There is no mention on timing of the effect the alert is referencing, nor does it say "when the impacted routing shall be shown." Thus, any resulting change to routing implemented by the consumer is based on at least some degree of conjecture, for better or for worse. Separating impact time and active time is an interesting alternative solution. It's more specific and enables a producer to explicitly define the impact time separate from the alert's display time. In line with my comment above on
Is there a use case where a producer needs to be able to define the |
I agree. And while I didn't explicitly state it in my original suggestion I always intended that the current field would be one of the two. When you share the spec right now, I think it's more clear than it is in practice. We often find that consumers will show the alert (text) and its impact (using highlights or icons on stops, for example, to mark closed stops) for the entirety of that period. Consumers are generally treating I could go either way on adding a new |
While I agree this boolean could be in the feed header instead of each alert, I would imagine that some agencies would want some, but not all, of their alerts to impact trip plans. For example, an agency may want trip cancellation alerts to make it so cancelled trips do not show up in trip plans while they want to publish stop closure alerts at the route level and make them informational only (no impact to trip plans).
The new boolean discussed here would provide this functionality, but until all producers and consumers add support for it there is still a need to document what consumers can/should/must do for NO_SERVICE alerts in feeds that don’t include this new boolean. The following is a thought exercise to see how we might be able to document the current state and also suggest the preferred future state ( If The ambiguity in there, both in the explicit “undefined” statement and the implicitly undefined timeline for consumers supporting the new field, makes it not terribly appealing, but I’m not sure how we avoid the ambiguity while still accounting for the current reality and known variable implementation timeline. But maybe others have ideas. On the topic of |
|
There’s been a lot of talk about the period of communication vs impact, but one other common case where alerts are misused for routing change is a too broad selector that’s used. For example, an alert for a stop that is cancelled is assigned to a There’s been a pointing out of errors where Transit showed |
|
@gcamp This is a similar concept to the communication vs impact dates, but in another form. Agencies want to control who sees the alert, so they select the entities they want to communicate to (often those that are indirectly impacted) instead of the entities that the alert impacts directly. "I want everyone riding Route 5 to see this alert, even though it only impacts one stop on the route directly." This one is harder for me to come up with a solution for aside from reducing it to "us software producers should design the software to be more clear to agencies what will happen, and agency staff should get used to not having that level of control over third party apps." Perhaps there's room for some kind of parallel |
To weigh in on this, for our planned disruptions, we utilize multiple service alerts to accomplish this and feel this is important for riders to be aware of across the entire route-
Redundant? Maybe, but accomplishes the needed task. Unplanned disruptions are a different story but would likely be the same once we get the level of automation we desire in place. And for the record we have accidently closed entire routes via NO_SERVICE, but those instances are corrected super quick 😨 |
|
There has been a lot already said in this thread and I’m about to say some more, so apologies in advance 😇 Regarding the larger question of how alert data should (or shouldn’t be used): at the end of the day, GTFS is data, not a mandate. We reserve the right to use (or not use) that data in the way we think is best for our users, possibly in combination with other data sources. Across the full scope of transit data, that can involve us extending the schedule of expired feeds, fixing bad stop locations, blocking feed updates with suspicious changes, doing our own real-time arrival predictions, etc. While we don’t always get things 100% right, overall we have strong evidence that these actions help our users. Which brings us to alerts. We definitely agree that the alert spec could be improved to better capture the intent of the transit operator, but at the end of day, we do not intend to stop using alert data (whether it be from GTFS-Realtime, Twitter, etc) to tweak routing to show alternate routes where appropriate, because we think it helps our users. As such, we are -1 on any proposal that would imply or require otherwise. That said, we recognize that there can be a mismatch in expectations from transit operators in how we use alert data. Operators also sometimes just get their alert data wrong, even when their intentions are correct. As such, we already have a number of automated and manual processes in place to try to identify these mismatches. We think the spec should be improved in this regard (more below), but there has been a specific suggestion that a new flag indicating if an alert should be used to update routing. While we don’t necessarily oppose this addition, I want to call out that we would still continue to review alerts with In terms of improving the spec, we believe that it’s worth extending the existing Alert model, as opposed to introducing a new data type. This reflects that the existing alert model is not that far off from what we’d need in a new data type. It also reflects that we believe that this data will likely be managed by the same system for many operators and we are likely to achieve more adoption from operators in this way. Given that, we are supportive of spec additions to clarify:
|
|
Are you sure you represent Google, because such statements would fully apply to Microsoft Internet Explorer, and their efforts to "standardisation". Doing what a consumer thinks the intention of the producer is versus what the producer is asking to show is in my perspective a direction I don't want to see standardisation folks made.
This is a blunt 'we do what we want'. And I am thinking about a smart thing that @e-lo previously suggested. We need to completely rethink our data licenses with the above statements. |
|
Thanks all the inputs; I’ve learned a lot from this discussion 🙂 From the conversation, it’s clear that there is an objective ambiguity regarding whether NO_SERVICE alerts should be used in routing, and this could potentially lead to riders receiving incorrect information (as in this example). This ambiguity seems to be an unintended consequence, arising from a lack of consideration for such cases when writing the specification, rather than a deliberate allowance for different interpretations. On the question of whether NO_SERVICE alerts are allowed to be used in routing, I would like to echo @SteveGladstone point from the perspective of riders. We believe that GTFS has followed the practical principle of maximizing rider benefit, which is one of its great strengths, even if it sometimes appears to sacrifice detail or elegance for the sake of practicality. Additionally, as seen in the discussion of boolean values and Given all of this,, I’d like to confirm with everyone whether @stevenmwhite's proposal to introduce the new fields |
|
The The routing question is independent of the above. |
|
I agree that this is two questions. I am (of course, I proposed it) in favor of clarifying the spec by including two separate time periods -- one for the period where the cause/ effect have an impact on operations and one for the period when the message is desired to be communicated. Perhaps it needs some specific details like should the communication period always include the active period or how should it be interpreted if the periods are completely separate or can either field be blank, what if there's only a communication period and no impact period? As for routing, I think it will be hard to standardize this, and I foresee it will most end up with different consumers building the functionality that they want to implement for their users. As a rider, I would expect an app not to send me to a stop that is impacted with no service, so I personally would choose to use an app that does include certain effects in its routing. Regardless, adding the two time fields will make it less likely for apps to erroneously change routing during a period when an agency was just intending to communicate a future impact. I would suggest moving forward with that proposal and separating the routing discussion. |
|
Adding that could be an opportunity to say that if there is an active_period and the effect is NO_SERVICE then the alert can be used to modify trip planner behaviour. |
This PR is intended to close #469 with a solution different than the one initially proposed in the issue, based on the feedback received.
The rationale, more context and reference materials for this PR are available in this document: https://share.mobilitydata.org/alerts-proposal.
Issues
What the spec currently says
Proposed solution
Given that Alerts are easier to produce and are generally more efficient and informative in describing cancelations, we propose that:
Alerts should be used for notifying that a stop will be out of service for extended periods.Alerts can be used by consumers to modify trip planner behavior.This PR adds these three statements to the GTFS Realtime spec.
Does this seem like a reasonable solution?
Do we need to add more details to what "extended periods" means?
Tagging folks who provided feedback to the issue @optionsome @dbabramov @gcamp @leonardehrenfried @IvanVolosyuk.