-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Too small interval in PT transfers #2115
Comments
I believe I fixed the issue. The transfers.txt parsing is fine, min_transfer_time gets saved in memory. However, when adding the transfers to the departure timeline ( In the GTFS data I used, transfers.txt only has from_stop_id, to_stop_id, transfer_type and min_transfer_time info. For that reason, the condition My solution is just assigning the min_transfer_time in the transfers array (which always has only one item in my case, there is always only 1 transfer between two stops):
I can fork these changes to this repo, but first I'd like to know if this doesn't break anything. Is this supposed to be like this or is it something that you missed? What is exactly the purpose of the |
Investigating.. |
Ah yes. Wow, this code is wrong. This was my rushed attempt at a fix for a serious performance problem -- the regular case (no route-specific exceptions) was always rolled out to one rule for every route. That was correct but slow. Now it's faster but wrong. There will probably be more wrong cases. I have to rewrite this and test it properly. I think the current structure doesn't work anymore, it will always be one special rule on top of another. (Help appreciated!) But your solution is clearly less wrong, so I would merge a pull request right away. Thanks a lot! If you look at
This is where you could add a test that the minimum transfer time is correctly processed -- that transfer should have one, and it's wrong now. With your fix, it should be correct (non-zero). |
Thanks for the feedback, I'll merge the changes ASAP. |
I’ve been having some problems with the PT routing but have been able to get around them. This one is tricky though.
In this particular case, the departure time of the second transport is just 44 seconds after the arrival time of the first transport, and since the stops aren’t really that close, it would be impossible in a real life scenario to do that transfer on time.
The transfers.txt file specifically states a min_transfer_time of 303 seconds for a transfer between those two stops, which is clearly not being respected. Is this a bug?
The text was updated successfully, but these errors were encountered: