My current intuition is that we should do away with pure transit walks, pure drt walks, etc.
To remind: Such walks come up when they are faster than the "modal" connection. Typical examples of this are walks to pt/drt stops, followed by walks to the destination, without having taken pt/drt in between, since then the direct walk is faster.
However, they have odd consequences. I don't want to list them, but rather suggest what we should instead leave the computed pt/drt route in place even if "odd":
For drt, this often is "walkToDrt--walkToDestination". This is typically caused by not starting/ending in the service area. I think it would be better to see that and then actively select a different mode, then being kicked into some not-well-defined drt_walk.
For the pt router with drt access/egress, this may even be drtToPtStop--drtFromPtStop, which may be perfectly reasonable in particular in situations where drt is regulated to only access/egress pt stops.
One reason for not converting drt_walk/transit_walk to normal walk is that then the info about the router from which it came is gone, causing problems with matsim's mode choice approach. Another reason is that it would introduce a flow towards walk, without a flow in the other direction, potentially because a user did not define walk as mode in the first place. I now think that users should define all modes explicitly, so if direct walk is an alternative option, then matsim mode choice will eventually find it. And if it is not, when we should not automagically invent it.
I find things much easier to debug when I still see these possibly weird trips. Maybe someone just misses the last bus, maybe someone is outside the drt service area.
It would reduce the number of automagic config parameters.
Note that when we don't replace into transit_walk/drt_walk any more, then recognition of the original router would be possible by the type of the interaction activities.
I would vote for removing these walks entirely, since in addition their other parameters such as speed and utility are not clear. The only thing that will remain would be non_network_mode, which is necessary to connect facilities with links with which they are not directly connected (e.g. pt stop facilities not on the car network, activity facilities connected to car-only links but a bicycle trip trying to leave/reach them). Since such transitions are difficult, we might have switches, but note that with such a switch we will not get the complexity reduction in the config.
[Created via e-mail received from: "Nagel, Kai, Prof. Dr." <email@example.com>]
The introduction of routing mode MATSIM-26 partly solved this issue, because it removed the need to have separate walk modes for direct walks when the intended main mode was unavailable. The modes drt_walk, transit_walk, drt_fallback are all removed now. Instead a leg of leg mode walk and routing mode pt/drt/etc. is used for direct walks described above.
However, we still have direct walks and the default MainModeIdentifier in e.g. ModeStatsControlerListener identifies such direct walks as pt/drt/etc.