You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: