How should detours be handled? #152
Comments
|
These are important questions and a great opportunity for making TheTransitClock more dynamic and valuable.
Whatever underlying structures are developed to support detours / dynamic re-routing, they should definitely support translation into GTFS-realtime. For example, the current GTFS-realtime spec supports trips with status "Added" or "Canceled", and StopTimeUpdates with status "skipped". I would also recommend checking out the GTFS-ServiceChanges proposal and discussion, which would be a new extension covering more dynamic re-routing including changing shapes, and creating new stops, routes and trips on the fly. |
|
We would not be able to match while it is on the detour. The vehicle state could reflect it is on a detour so would avoid it being made unpredictable because of N bad matches. |
|
Just wanted to update this thread - the most recent proposal for Service Changes / detours in GTFS-realtime that we seem to have a general consensus on is: It's linked at the very bottom of the thread that @nselikoff linked to above (google/transit#113 (comment)). |
|
If we take it that we know about a diversion (either by detection or service changes) how do we represent this in TheTransitClock. Do we try to update the current in-memory schedule on the fly or do we add a detour model layer that we can query before we take into account each stoppath travel time and dwell time in a prediction? So, if stoppath is effected by detour add detour total travel times/dwell times to the predictions for stops passed the detour. |
|
Also, do we represent the detour in the realtime feeds (service changes) coming from TheTransitClock? and provide predictions for the new stops on the detour? |
This would be amazing if possible. |
|
How is matching affected? How does this affect the SpatialMatcher and the TemporalMatcher? The current SpatialMatcher matches to the closest point on the static route. This would need to be changed so it could match to a point on the detour as well as the static route. The TemporalMatcher would also need to say so it is possible to be on the detour based on the previous match and the time past. |
|
Sounds silly to say it but detours cannot have detours. One detour would replace another. |
|
Started work on branch tc_issue_152. |
|
Focusing on GTFS-NewShapes piece of GTFS-rt Service Changes first. |
|
@vsperez This project may help with creating a test service changes feed. |
|
@scrudden |
|
By the way. The whole trip-update message is: header { |
|
@vsperez Could you publish the KML file you used and the related GTFS file somewhere? |
|
@scrudden Yes! Although I believe there should be a |
|
Oh, and |
|
Ok. Thanks for the feedback. Actually the lack of thouse fields is a bug.
They are supposed to be there.
El lun., 30 de mar. de 2020 14:09, Sean Barbeau <notifications@github.com>
escribió:
… Oh, and shape_dist_traveled should be populated with a valid value
instead of 0.0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#152 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJUAAGH2E7CKEAPU5XYIBK3RKDG6HANCNFSM4IXPVJQQ>
.
|
|
@scrudden I just fixed the shape_dist_traveled and shapeId. This is what I got. Is it correct the gtfs version, or should I use other? |
|
Looks good. I am not sure what is expected in terms of the version number. @barbeau Can you chime in on this? |
|
Do you mean |
|
Yes, that is what I meant. @vsperez Is that what you meant by version in your earlier comment? |
|
How would a stop on a detour be encoded using GTFS service changes? Should we relate a stop to the shape it is on? |
|
Yes, I meant gtfs_realtime_version. Thanks. |
@scrudden I'm double-checking this, but here's my current understanding - If the stop_sequence of stops changes due to the detour (including added If the stop_sequence of stops does NOT change (e.g., no added stops, no change in stop pattern/geometry), then you can reference the new shape from the TripUpdate.trip_properties (trips that just have |
|
@barbeau How would OneBusAway deal with this new trip? |
|
@scrudden None of the |
|
If on a detour this will effect the recording of arrival and departures. We should not record any for the skipped stops. |
|
Is a detour a change to an existing trip or is it a completely new trip? I am conflicted/confused on this one. The Services Changes spec would point to a new trip (if there is a stop on a detour) and the shape provided would be the whole new trip. In my mind a detour is a change to an existing trip and the shape in a detour model would represent the changed piece of the route shape. |
|
We will need to have the ability to handle stops on detours so have refactored the diversion model to include diversionStopPaths. |
|
Indices class will need to be able to represent a vehicle on a diversion and where on a diversion it is. |
|
@vsperez Just in case you have not seen. This comment from Trapeze describes a User Interface to draw a detour as you intend doing. This gives me confidence that this is an appropriate thing to do. |
|
@scrudden, I have been taking a look at the detour managing, and I have a small issue. If the "basic detour" has a tripId on it is quite difficult to handle. I don't know what is better:
|
|
@vsperez Sorry, I do not understand your comment. Could you perhaps give an example? |
|
@scrudden If I want to create a detour, I want to do it for several trips, even several days. In this very moment, the diversion PUT method receives: But If I am a user I would like to provide something like: So In this case, I a have a conflict between UI and operational data. |
|
I think the issue is, should a detour be related to a route or to a trip? Maybe we should have the option of both? So, if tripId is provided then have it specific to the trip but if routeId alone provided then apply detour to all trips on the route within the time period. Does that sound like a plan? |
|
Yes it does. I will make tripId optional. |
|
Hi.
What I need to do now is to build the detour given the route information (shape, stops, etc) and the alternative paths. Of course to build the alternative paths in the correct format. Please let me know if there is a class to build that easily. |
|
Hi Vicente, The definition of the variables you detailed are correct. There are detour model classes that you could populate. Is this what you are looking for? Cheers, |
|
Actually I am looking for some method that, given a coordinate and shape,
returs the closest path or parths. One that would be easy to use. If not,
I will implement it or search in the code. I know some exists, but the one
I know are not easy to use.
El dom., 28 de junio de 2020 06:33, Sean Óg Crudden <
notifications@github.com> escribió:
… Hi Vicente,
The definition of the variables you detailed are correct.
There are detour model classes that you could populate. Is this what you
are looking for?
Cheers,
Sean.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#152 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJUAAGCCWGXMLLFEZLC7MWTRY4L65ANCNFSM4IXPVJQQ>
.
|
|
Hi Vicente, This may help. The Vector class has some of the methods that could help. Cheers, |
|
It will help, thanks.
El dom., 28 de jun. de 2020 a la(s) 11:07, Sean Óg Crudden (
notifications@github.com) escribió:
… Hi Vicente,
This may help. The Vector class has some of the methods that could help.
Cheers,
Sean.
https://github.com/TheTransitClock/transitime/blob/485eead484e5226ac971dbb364771950cf0402f7/transitclock/src/main/java/org/transitclock/core/SpatialMatcher.java#L549
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#152 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJUAAGCRX7BAAMNXHBHTQJ3RY5MDVANCNFSM4IXPVJQQ>
.
|
If there is a detour that is not in the GTFS schedule how should it be handled?
We would have to know it is there to be able to do something about it. So the question is how do we know it is there? If a vehicle goes on a detour it will, I presume, miss some of the normal stops for the trip. Can we detect this? Well, we can detect stops that have yet to have a vehicle pass it today. Does this indicate a detour? No, what about the first vehicle of the day. What if we say if no vehicles past it for the last X trips that were supported to pass it then it is a detour.
Oh, but to be a detour the vehicles must come back to the route. We will need to check this for the last X trips. We need to check that their next arrivals on the route are at the same stop.
So if we know the stop is detoured what should we do? Stop prediction passed this stop as we do not know how long the detour is? That's OK but the people waiting at the stops past the detour will not see any prediction for the vehicle so think it does not exist.
Just keep showing predictions as normal. This means that they will be incorrect for the passengers after the detour but at least the bus will exist. It will disappear though when it is on the detour as it will no longer match to the route.
The other option is to try and predict the travel time for the detour based on the time taken by the last X vehicles that took the detour.
The text was updated successfully, but these errors were encountered: