In OTP2 transfers is a criteria in the McRaptor search, so adding a cost for transfers have no effect. But, after the raptor search is done some of the filters group itineraries together, with different number of transfers, and then keep the best itineraries based on cost. Hence, for the filter to account for the extra felt penalty of a transfer, the generalized-cost should incorporate a penalty for transfers.
Solution
In OTP1 the transfer cost was added during the AStar search, but it is not necessary to do so with McRaptor. Instead it is better to add the cost to the itineraries returned from the Raptor search before filtering them. This eliminate the extra work during the search (probably almost nothing, but it complicates the code) and allow for a much more sophisticated penalty function. This should be implemented using the strategy pattern - enabling swapping in different strategies. Note! The transfer cost strategy should be the same for all returned itineraries, but can be assigned based on input parameters and derived info like: minimum number of transfers, min travel distance, min travel time and all other request parameters.
It could also be tempting to add transfer cost when transferring between operators or modes, but this is not algorithmically correct and need to be added during the Raptor search.
Simple first implementation
Add a static cost to all transfers.
Increase the cost based on minTravelDistance or minTravelTime, Long distance travel vs commuting.
Problem
In OTP2 transfers is a criteria in the McRaptor search, so adding a cost for transfers have no effect. But, after the raptor search is done some of the filters group itineraries together, with different number of transfers, and then keep the best itineraries based on cost. Hence, for the filter to account for the extra felt penalty of a transfer, the generalized-cost should incorporate a penalty for transfers.
Solution
In OTP1 the transfer cost was added during the AStar search, but it is not necessary to do so with McRaptor. Instead it is better to add the cost to the itineraries returned from the Raptor search before filtering them. This eliminate the extra work during the search (probably almost nothing, but it complicates the code) and allow for a much more sophisticated penalty function. This should be implemented using the strategy pattern - enabling swapping in different strategies. Note! The transfer cost strategy should be the same for all returned itineraries, but can be assigned based on input parameters and derived info like: minimum number of transfers, min travel distance, min travel time and all other request parameters.
It could also be tempting to add transfer cost when transferring between operators or modes, but this is not algorithmically correct and need to be added during the Raptor search.
Simple first implementation