Skip to content
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

Frequency routes only explored on first round of repeated raptor search #80

Closed
mattwigway opened this issue Feb 22, 2016 · 1 comment
Closed
Assignees

Comments

@mattwigway
Copy link
Contributor

When we perform a repeated RAPTOR profile search, we add the frequency routes and re-run the search with the same output tables to add in the effects of the frequency routes. We mark every frequency route for exploration on the first round, but frequency routes will only be explored on subsequent rounds if their access stops are relaxed in the frequency search. Since we're now using a separate data structure for each round, we will never explore frequency trips that can only be reached by first riding a scheduled trip.

It appears that this is not an issue in OTP, because we're not storing separate output tables for each round.

@mattwigway
Copy link
Contributor Author

This issue is a little bit confounding to debug, because on initial inspection it appeared that is wasn't happening. It appears this was because my origin was near the frequency line, and as long as walking to the frequency line with no transfers is the fastest way to get somewhere in the first round (it would be, because you otherwise couldn't reach any place on the frequency line, because the first round has no transfers), the line will be marked for exploration in the next round. When you're not within walking distance of the frequency line, #82 masks this problem.

So I believe that the solution is to simply mark every frequency pattern at every round. It's also critical to ensure that the frequency search runs for at least one more round than the scheduled search did, so we are sure to catch opportunities to transfer to a frequency line after the last round of the scheduled search (this will be a more important point in networks that have relatively more frequency routes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant