mattwigway
commented
1 year ago The way the transfer preferences are written now is a bit different than the way they are described in the RAPTOR paper. In the RAPTOR paper, transfer preferences are only used to choose a board stop. If a n transfer route has a lower transfer preference than an n-1 route, it won't be found. See also #32 .
30 attempts to add a tiebreaking such that we find the lowest walk distance route that arrives at the earliest possible arrival time (i.e. using walk distance to break ties). However, this is not actually the case. Consider a network where there are two possible buses to take to a transfer point, one that arrives at 9:10 and one that arrives at 9:30. The latter is a 100m walk, while the former is a 250m walk. The bus to the destination leaves at 9:40, so you can take either of the first two buses to access the transfer point. But at the transfer point, the 9:10 arrival is optimal and will be chosen. Short of doing an actual multicriteria search, this is not solvable, as both the 9:10 and 9:30 may be optimal for some journey suffixes. This is even noted in the section on transfer preference in the RAPTOR paper:
This gets even more hairy when range-RAPTOR gets involved. Suppose you had a network like the one above, but instead of the 9:10 and 9:30 arrivals occurring at the transfer stop, the 9:10 arrival occurs some distance away, and requires a long transfer. Suppose further that the 9:30 arrival departs later than the 9:10 arrival. range-RAPTOR will initially find the 9:30 arrival and set the board stop on the trip to the destination based on it. Later on, when the 9:10 arrival becomes possible, the path to that transfer point becomes to take the 9:10 arrival and then walk. Even if there is another place to board the trip to the destination with less walking than the 9:10 arrival (but more than the 9:30), it won't be found because the board stop has already been set in a later minute. This can be avoided by only using updated stops in the range-RAPTOR output.
Then again, maybe it's all fine. The point of #30 was to avoid ladder transfers (#26) and excessively long initial walks, and it still does that. We just can't claim that the results are optimal in terms of walk distance, but that was never the point. The way it's implemented in