-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GTFS Trip-Modifications #403
GTFS Trip-Modifications #403
Conversation
Fix typo Add images Update image width Add newlines Add newlines Update images Italic for image description Update SLO travel_time_to_stop is optional Proto : all feild optional Add references to GTFS-Static
Can you provide an example trip updates file with a detour? |
I don't think that one consumer and one producer justifies it from removing it as experimental, neither it being available for two years. The usage is just too sparse. My expectation as a producer is that more than half of my known consumers would be supporting this. |
One question: do these detours happen so spontaneously that you need a realtime update for that? I would have thought that you know them at least a couple of days in advance and could put them in a static GTFS feed. (I don't work for an agency though.) |
@leonardehrenfried we have certainly seen spontaneous reroutes, for example for tram rail blockades. |
Unfortunately, my agency often has to implement detours with no notice. Medical emergency, police activity, public demonstration--lots of unplanned stuff can clog a street. Even if we did always have a day or two of advance notice, producing a new GTFS Schedule file, publishing it, and making sure all data consumers ingest it in that span of time is a dicey proposition. Even Google prefers receiving a new GTFS Schedule file several days before the changes go into effect. So I see being able to publish detours in a realtime way as an acute need. |
That does not mean magically journey planners can implement such functionality. Otherwise the delay for processing the actual schedule wouldn't be a thing :-) |
I think the fact that this is launched in Transit already proves that it can be implemented in rider-facing apps. I didn't say "journey planners" because I'm not exactly sure how it shows in the planned trip part of Transit app, but I'm sure @gcamp can answer that. And for what it's worth, there's always some differences in what various consumers support... Apple, Transit, Google, and others all launched support for trip cancelations at different times, some show real-time passenger load, some don't, etc... We're planning to support this as a producer in whatever way it's adopted soon and are in favor of the general concept. Some others on my team are going to review the details and we'll offer specific comments if we have them, but it's a general +1 from GMV. |
Most transit trips are taken on routes riders are already familiar with, so they don't need journey planners, but they do use real-time predictions and need to know if their route is detouring and where to get it. |
We’re still reviewing but the following paragraph stood out during an initial review:
What It would be helpful to understand the reasoning behind the decision to treat all |
Oh sure. You can implement many things if the performance does not really matter, and falls completely outside the scope of the journey planner algorithm used ;) So if that algorithm needs the complete network, or would need to recompute in order to facilitate transfers, that has an impact. And sure, you can implement this trivially using CSA. Now lets discuss multi day detours... which is allowed in this pull request. |
@doconnoronca good point, I'll follow up soon with this.
@skinkie From the Specification amendment process, we only need one producer and one consumer to move it to the main spec. And at the opposite, we're supposed to either delete or promote to the main spec any experimental fields after 2 years (that last part hasn't been followed very well). All the non-experimental spec changes that happened since the spec is on Github either have 3 or less producer and consumer combined : #229 #214 #210 That said, I understand this is a big spec change and if the community is more comfortable being an experimental field that can work for us.
@leonardehrenfried other gave good examples but I'll add that the best practices mention, "If a service modification will go into effect in 7 days or fewer, express this service change through a GTFS-realtime feed (service advisories or trip updates) rather than static GTFS dataset."
@skinkie @stevenmwhite our implementation affects our nearby functionality, route detail (where you see the shape, etc.) and also the trip planner. Temporary stops are taken into account, as you would expect. Performance-wise, there's no degradation that anyone would notice. On processing time, we're able to process the new data in a few minutes in the vast majority of the cases. We need to keep in mind that detours don't affect the entire system, but if a Trip-Modification feed affects every single route, our processing time would be similar to a new GTFS (but for us that takes minutes and not hours). I understand this feature might be hard to implement for some consumer. Happy to take feedback on how to improve this. However, I don't think this would be a reason not to approve Trip-Modifications, especially that Trip-Modifications are strictly improvement for consumers that supports it and doesn't affect the consumer that don't.
Yes @sam-hickey-ibigroup, they would be I agree compatibility with Trip-Modification aware systems and non-Trip-Modification aware system might require a bit more thought. Let me know if you have suggestions; otherwise I'll work on improvements around backwards compatibility. |
This is something I also want to see addressed in the changes towards active particaption, far more important than mentioning where people work, or prevent trolling the spec. In my perspective a single vendor on either side does not cut it for 'promotion', that could still imply that there is proprietary work being done that no other party is going to be picked up, it being too complex or worse introduce patented processes. I obviously do like a consumer and producer validating the work before we merge it.
I know CSA and RAPTOR are unlikely to have issues. Our planner does not even care about how the detour is provided, as long the stops are known a priori. My case would be: could you do this kind of changes with transfer patterns?
I think we also need to start a chat about a producer. Hence some producers can not do this, only operationally implement this via a CANCEL and ADDED (or what the two are called these days). |
We (Arcadis IBI Group) are going to brainstorm some ideas related to this and review this proposal in more detail from producer and consumer perspectives. We’re planning to share our ideas and feedback towards the end of this week or next week. |
Using the existing trip ids should allow consumers who haven't been set up to handle this to work better. The stop sequence could be excluded for the stops on the detour. |
This directly breaks anything that asumes no update still exists. |
@sam-hickey-ibigroup If a consumer can support trip-modifications then they fetch the version that has this feature enabled and will get more details on the detour shape, temp stops, etc. We're definitely open to ideas if there's a way to better support backward compatibility with the trip-modifications feature enabled. The approach we have now seems to be working well for us so far. |
What is the worst that would happen? That there would be no predictions for that trip? If a different trip id used, would have the same effect. I expect most consumers are focused on getting the prediction for the stop without worrying about extra stops it doesn't yet understand. |
Yes, that the provided that is fully ignored because the provided data is ambigous and the producer thinks everything is a-ok. In 2013 we have made a clear description between directly consumable GTFS-RT and data that still requires integration. Deliberately leaving out a stop sequence number is one of the worst things to do. |
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 generally like this proposal because it introduces clear, usecase-specific updates rather than the TripUpdate
over which there is a lot of confusion on how to interpret.
Generally speaking I would be in favour of replacing any implicit fields, like the automatically generated replacement trip ids or a missing time of a stop time, with something explicit as this simplify the implementation of this feature.
Also I'm missing a little bit of language on how to apply TripUpdates
to these modified trips.
tl;dr The changes proposed here have the potential to allow a huge leap forward in how transit agencies communicate detours to customers, but the way the proposed changes are written now to cancel and replace all Here is our detailed feedback. Changes to automatically canceling and replacing trips The
We would like to see the portion of this that automatically cancels trips removed. We agree there should be an option for consumers to cancel trips, but requiring cancellation has many major implications for maintaining consistency between all of an agency’s real-time feeds. We expect it will be years, if not longer, before many agencies are able to update their systems that produce and consume GTFS-realtime to support automated cancellation and replacement of trips affected by trip modifications. While it makes sense to cancel and create replacement trips in cases where the scheduled stop times of trips change, transit customers will still receive significant benefits if an agency publishes trip modifications without any changes to stop times. For example, publishing a In cases where an agency wants to cancel and replace trips, we would like to see the following explicitly added to this proposal:
@mads14 To your points on backward compatibility, yes, your current approach sounds reasonable for maintaining backward compatibility for consumers. But without the changes noted above, we expect producer adoption of GTFS Trip-Modifications will be limited. Clarify replacement stops do not have to define changes to travel time In
With this: Each Add last_modified_timestamp to This would make it easier for consumers to know which Clarify the feed where Our preference is for Grouping trip modifications by stop pattern We would like to hear input from other producers and consumers about this:
As noted at #369 (comment):
We understand the benefit of grouping by Finally, a big thank you to Transit and Swiftly for all the initial work on this. The results of this effort for the first 3 agencies using it is truly impressive. Looking forward to working together to refine these spec changes to encourage and enable more widespread adoption and availability of this data. |
Hi @sam-hickey-ibigroup, Thanks for the detailed feedback. I work with @gcamp at Transit on the GTFS-TripModifications spec, and next week we'll be making some changes to the proposal to clarify and address these comments.
The trips created through GTFS-TripModifications modify and replace each specified We'll clarify the spec to provide two explicit options:
Wording will be improved in both of these areas.
We wouldn't consume this field, as we compute a hash over trip modifications to look for updates instead.
In our definition, a stop pattern is the broadest possible grouping of trips that allows the start and end of each modification to the trip to be unambiguously identified by start stop sequence + # of stops replaced. In principle, detours could be defined by route and direction, but then I think the start and end of each modification would need to be identified by stop ID, which adds complexity and won't work on loop routes with repeated stops. |
I just want to take the time to thank @gcamp for taking the lead on this. MobilityData is actively analyzing the Pull Request and reaching out to Stakeholders that might be concerned by this change. We will share our findings with you here and provide a few comments soon. We also stand ready to support @gcamp 's efforts in reaching out to the community or provide a place for discussion if needed. We look forward to seeing the outcome of this RP. |
@npaun Looking forward to seeing your updates next week.
Even if Transit wouldn’t use this field, it would still be valuable to add. Other consumers may want to use it to know which One other thing that would be good to add within the |
…erpolation Less strong requirement to interpolate
f40bffe
to
7887381
Compare
We pushed two updates :
|
Also as requested, here are two example feeds from Swiftly (thanks @mads14 !) :
On the Trip-Modifications feeds, you can remove the Finally, an update on existing consumer/producer : we also have the STM using Trip-Modifications on their website. We have some producers at different stages of implementation but nothing to announce yet. |
-1 from TransSee The proposal is inflexible and overly complex compared to adding trip updates to describe detours. The issues with file size can be addressed by putting the upcoming changes in a separate feed, reducing the excessively high period that they are excluded from the GTFS and making the link between the real time data and the schedule clearer. |
I didn't follow this proposal very closely over the past few months but I'm pleased to see that the concatenated ids have been replaced which was my biggest problem with this. I have a question about the protobuf schema having lots of optional fields but generally I'm happy with this proposal. |
+1 FlashWeb as a producer. We have encountered several situations in which unplanned utility works, accidents or weather cause short notice detours, and it is definitely something that degrades the experience of users that plan their trips through open data consuming apps. We'd really appreciate a standard way to quickly exchange this kind of information and therefore provide a better overall experience to riders. We have experimented with canceling affected trips and publishing image links to generated maps of the detour, therefore making use of the existing Trip Updates functionality to handle the mentioned cases, but it is absolutely a subpar solution, in terms of impossibility to filter by accessibility features of new stops or modified trips, navigating to those locations or just comprehension of the message by international users. This PR solves our issues as is and having it adopted by high profile consumers would constitute the business case presented to operators in order to put in the time and resources to upgrade their systems with this extended functionality. |
My interpretation is that to not cancel any stops the producer needs to provide But it's not clear to me how And to confirm, when no stop times are missed, the |
Editorial, formatting clarifications
Co-authored-by: Sam Hickey <[email protected]>
Thanks @jfabi @bdferris-v2 @sam-hickey-ibigroup for the comments! I applied directly most of your proposals.
That's right that wasn't clearly defined, I added some clarification here. |
Thanks for the clean up and the clarifications. +1 OpenTripPlanner |
|
Thank you for taking the time to vote @yannick-b . Unfortunately, we cannot tell wether you are voting + or - 1 with the current format. Please revise your vote to reflect your position on the matter. Thanks Edit: vote was corrected |
+1 Arcadis (formerly IBI Group) |
+1 from the @mbta. |
The vote has concluded. +1
- 1 :
Since this is an experimental field, the vote passes. Thanks everyone! |
When will this be merged? |
The vote has passed. GTFS Trip-Modifications will be merged to the spec. Trip-Modifications shall be experimental for at most 2 years. As stated in the GTFS Realtime Amendment Process:
Thank you to everyone that participated in the development and see you in less than 2 years. |
* Editorial changes to Reference.md (google#422) * Add dataset publishing in index * Fix link * Clarify stop_timezone description * Make references to other files consistent * fix link in Dataset Publishing Guidelines * Fix links * fix(gtfs/spec/reference): remove extra backtick in`record_id` description (google#431) * GTFS Trip-Modifications (google#403) * Add Trip-Modification, make shape non-experimental Fix typo Add images Update image width Add newlines Add newlines Update images Italic for image description Update SLO travel_time_to_stop is optional Proto : all feild optional Add references to GTFS-Static * Create a page for TripModifications entities for consistency with TU and VP * Clarify providing TUs for modified trips and ReplacementStop time interpolation Less strong requirement to interpolate * Fix first_stop_reference.png not having the right image + optimize image size. * Fix optional/require for Stop message * Clarify behaviour and linkage to TripUpdates * Apply Modification clarification proposed changes Co-authored-by: Paul Swartz <[email protected]> * Use ModifiedTripSelector instead of concatenation of IDs Update langage Update namign * Add details on behavior when is provided * Remove modifications_id * Fix after comments from @bdferris-v2 * Add note about producer needed the two versions of trip updates * Fix bad relationship mentionned, + force no other entity when using ModifiedTripSelector * Changes after Jan 10 call * Add experimental notices * Remove mention of stop pattern * Use stop selector instead of stop sequence only * Update to end_stop_selector * Update proto with start/end stop selector * Add selected trips * Update reference with SelectedTrips * Update trip modif doc * Add last_modified_time * Add missing start_times in pb * Fix typos, fix description of selected trips * Fix typos Co-authored-by: Nicholas Paun <[email protected]> * Update reference for clarity * Clarify and remove duplicated information * Consistancy * Revert correctly shape experimental * Editorial, formatting clarifications * Apply suggestions from @sam-hickey-ibigroup Co-authored-by: Sam Hickey <[email protected]> * Update documentation images with new fields, add source files * Clarifies behavior of propagated_modification_delay when no stop_time is cancelled * Remove extra word * Sync .proto and reference files --------- Co-authored-by: Nicholas Paun <[email protected]> Co-authored-by: Paul Swartz <[email protected]> Co-authored-by: Nicholas Paun <[email protected]> Co-authored-by: Joshua Fabian <[email protected]> Co-authored-by: Sam Hickey <[email protected]> * GTFS-Flex [Voting ver.] (google#433) * Add 3 "location" files and booking rules file * Modify stops.stop_id * Modify routes.continuous_pickup/drop_off * Modify stop_times.arrival/departure_time * Modify stop_times.stop_id * Add stop_times.location_group_id & location_id * Modify stop_times.stop_sequence * Add stop_times.start/end_pickup_drop_off_window * Modify pickup_type & drop_off_type * Modify stop_times.continuous_pickup/drop_off * Add pickup/drop_off_booking_rule_id * Add "On-demand Service Routing Behavior" * Modify conditions for start/end_pickup_drop_off_window * Remove unnecessary table name & editorial changes * [GTFS-Fares v2] Clarification: Fare product definition (google#426) * Clarify fare product definition * fare media clarification / remove desc in amount Add explicit interaction w/ fare media, Remove individual explanation in non-primary keys * Editorial change * Update gtfs/spec/en/reference.md Co-authored-by: isabelle-dr <[email protected]> * Update desc of fare_product_id Co-authored-by: isabelle-dr <[email protected]> * Editorial changes for fare_product_id * change "segments" to "legs" --------- Co-authored-by: isabelle-dr <[email protected]> * Update CHANGES.md (google#440) * Added data example page links in stop_times (google#443) --------- Co-authored-by: Kayla Firestack <[email protected]> Co-authored-by: Guillaume Campagna <[email protected]> Co-authored-by: Nicholas Paun <[email protected]> Co-authored-by: Paul Swartz <[email protected]> Co-authored-by: Nicholas Paun <[email protected]> Co-authored-by: Joshua Fabian <[email protected]> Co-authored-by: Sam Hickey <[email protected]> Co-authored-by: Tzu-Jen Chan <[email protected]>
His anyone implemented the updated version of Trip-Modifications that uses the ModifiedTripSelector? The regular Maryland MTA feed from Swiftly doesn't include it and the version with "enable-feature=trip-modifications" appears to still use the original method. |
We're working on updated implementation right now |
Following the proposal of GTFS Trip-Modifications in February, we are now ready for the pull request stage!
As a reminder, Trip-Modifications are modifications done to a trip to modify its shape, remove stops that are not served anymore, and potentially add temporary stops. Trip-Modifications is mainly used in a detour use case.
Today, we're launching the detour feature in Transit for more agencies with Trip Modifications produced by Swiftly! Now that there is one producer and one consumer, the current PR is not an experimental field and actually removes the experimental tag for
Shape
, which has been in the spec for 2 years.Feel free to ask questions, or give feedback!
Edit: see example feeds here.
Latest changes before a potential experimental vote are up
Example of the feature in practice: