Closed slvlirnoff closed 2 weeks ago
walkReluctance is what should be used to limit walking and experience show that 10/20 are good values.
This out of date, good values for walkReluctance
is in the range 1.0 - 5.0
.
Also potentially a non-linear cost for walk could be interesting, it is increasingly frustrating/uncomfortable to walk over time, 1,5,10,15mn transfer would not be ranked by the users as 1,2,3,4 on a scale of "painfulness".
All factors(also cost) must be linear increasing to be valid in Raptor search, exponential factors can not be used and would produce strange results.
General question of the 'cost'
We plan to replace the existing cost calculation in the heuristics with a Raptor search with cost as a single criteria. This is described in Fast and Exact Public Transit Routing with Restricted Pareto Sets, by Delling ++.
All factors(also cost) must be linear increasing to be valid in Raptor search, exponential factors can not be used and would produce strange results.
Yes, I was thinking that we could have exponential cost on the transfers, based on the duration, but this might produce strange results, where we ride one bus stop potentially the wrong way, in order to split a long transfer into two
General question of the 'cost'
We plan to replace the existing cost calculation in the heuristics with a Raptor search with cost as a single criteria. This is described in Fast and Exact Public Transit Routing with Restricted Pareto Sets, by Delling ++.
Thanks, I'll re-read this one!
All factors(also cost) must be linear increasing to be valid in Raptor search, exponential factors can not be used and would produce strange results.
Yes, I was thinking that we could have exponential cost on the transfers, based on the duration, but this might produce strange results, where we ride one bus stop potentially the wrong way, in order to split a long transfer into two
I see and you are right about exponential costs, however in this case if the results are otherwise similar (similar duration/arrival time) I'd prefer walking twice 10mn instead of once 20mn.
Outside exponential cost you could have fixed additional penalties if you walk more than 10mn. That would probably not be considered exponential as this would be similar to some boarding cost or trips having penalties or preferred costs and could help keeping a small walkReluctance factor and still favour transit routing.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days
Thanks @hannesj for reopening this one.
As discussed on gitter: the small bump in speed performance of some locations after the speed test config fix is due to larger walkReluctance value than the default.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days
I've been looking into adding a few performance test cases for Switzerland and I was investigating why one of my test case was significantly slower in a deployment compared to the speed test framework.
I've narrowed it down to a different walkReluctance value. I've seen that it has a lot of impact. See below search case 1-4 are almost not affected, these are rather direct searches with small agress/egress walking path. Search 5 necessitate a medium walk transfer between station in the middle and is relatively affected and search 6 has longer agress/egress edges and is strongly affected.
As you can see the duration explode quite quickly even for small values, this is a combination of a large search window (8h itinerary) and the following side effect: Heuristic is pruning paths based on duration, cost, etc. for the minimal potential cost, it uses the heuristic duration multiplied by the smallest factor (usually 1 for transit, potentially less for RAIL in some deployment). It's compared against the actual cost of the solutions found so far. As the ratio between minFactor and walkFactor increases the heuristic is more and more optimistic and eventually doesn't prune anything leading to very slow searches. (Interestingly enough increasing walk reluctance will make the algorithm explore potentially more walking transfers because of the heuristic "loosening" impact.)
I'm fine with that however the documentation roughly says: walkReluctance is what should be used to limit walking and experience show that 10/20 are good values. I feel that this should be revisited or a comment should be made on speed performance/heuristic impact.
I've always found strange to have such a high (suggested) factor for walkReluctance, that's seems an artificial way to fix something else (a lower boardCost and walkSpeed could work just as well with lower performance impact?). Also potentially a non-linear cost for walk could be interesting, it is increasingly frustrating/uncomfortable to walk over time, 1,5,10,15mn transfer would not be ranked by the users as 1,2,3,4 on a scale of "painfulness".
Quick fix
Add a comment in the documentation about performance and potentially revist proposed values for walkReluctance.
As other quick fixes: if it's hard to keep track of transfer/transit duration I feel that the initial walking access and egress cost could be added to the heuristic min cost with the correct factor to reduce their impact on the performance overall. Potentially at least as 'the minimum access and egress of all access and egress'. Also is it really relevant to consider the cost in the heuristic pruning? As the minCost from the heuristic is not really correct by default, this could be another potential quick fix.
Also walk reluctance could be more granular, i.e. you might want to avoid transfering by walking if there's a nice transit connection, however walking between platforms of the same parent station could have a different reluctance factor (also to avoid filtering artificial long walk due to poor OSM mapping/platform linking and/or waiting for a later train connection because one train platform is closer to you).
General question of the 'cost'
There is one other aspect behind the scene here that is interesting to discuss : as implemented now the cost is roughly a translation of the number of transfers and the duration and the bests solutions for these two criteria are already considered in the ParetoSet as well as in the algorithm (through round and tripSearch). I guess this comes from AStar routing.
Shouldn't the cost be independent of these values to reflect better penalties or preferred options? That could also be easier to implement a list of fixed costs based on condition: boardCost, changeInStationCost, changeOperatorCost, fastWalkTransfer, longWalkTransfer, badSurface, dangerousArea, lowFrequencyTripCost, highFrequencyTripCost, onDemandCost, etc
I feel that if the 'cost' was a more relatable criteria it would be easier to maintain, manipulate and visualize:
All the above are not taken into consideration by the duration, number of transfers, etc.. and could be captured nicely into one cost-like critera and would be relevant for a user. Also these would be probably more easily explained in 'business' words and easier to justify and fine-tune.