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
We tried to configure network-routed walk trips today, which was quite complicated. The main problem is that "walk" is hardcoded in many places and does not fall back to a network-routed mode, especially in combination with public transport. At the end, we managed to set things up properly, but only by introducing a new "network_walk" mode which does not interfere with the initial mode. To ease the process in the future, we should add a couple of things:
TransitRouterConfig creates a NullPointerException if teleportedModeSpeed is null (but this is enforced if one wants to use teleportedModeFreespeedFactor): Instead, a warning should be printed that if somebody tries to configure "walk" as a network-based mode, it is better to define a new mode altogether.
SwissRailRaptor creates walk routes from scratch when no public transport route can be found. So this means even if one configures a "network_walk" mode that is used independently and/or as an access mode for SRR, SRR will eventually produce plain "walk" legs that one wouldn't expect any more inside the plans. Not sure how to fix this? Add a config option to SRR that defines the walk mode to fall back to and then use the respective routing module?
It would probably make sense to have an example in matsim-code-examples for a scenario with network-based walk. From all the trying around today, I have the impression that the best way is to create a separate network_walk network and configure a new network_walk mode in scoring, routing, and wherever else it is needed. Then the only remaining inconsistency seems to be the SRR issue from above.
The text was updated successfully, but these errors were encountered:
It would be very good to have this cleaned up the way you proposed.
by introducing a new "network_walk" mode
I think too, that this is the way to go. Even though "walk" suggests that it is the thing agents do when they want to go on foot, it is used differently in the simulation.
We tried to configure network-routed walk trips today, which was quite complicated. The main problem is that "walk" is hardcoded in many places and does not fall back to a network-routed mode, especially in combination with public transport. At the end, we managed to set things up properly, but only by introducing a new "network_walk" mode which does not interfere with the initial mode. To ease the process in the future, we should add a couple of things:
TransitRouterConfig
creates aNullPointerException
ifteleportedModeSpeed
isnull
(but this is enforced if one wants to useteleportedModeFreespeedFactor
): Instead, a warning should be printed that if somebody tries to configure "walk" as a network-based mode, it is better to define a new mode altogether.SwissRailRaptor
createswalk
routes from scratch when no public transport route can be found. So this means even if one configures a "network_walk" mode that is used independently and/or as an access mode for SRR, SRR will eventually produce plain "walk" legs that one wouldn't expect any more inside the plans. Not sure how to fix this? Add a config option to SRR that defines the walk mode to fall back to and then use the respective routing module?Also, see FreespeedFactorRoutingModule not creating NetworkRoute #2045: There is a difference between
NetworkRoutingModule
andFreespeedFactorRoutingModule
when the transit network and walk networks are disconnected.It would probably make sense to have an example in
matsim-code-examples
for a scenario with network-based walk. From all the trying around today, I have the impression that the best way is to create a separatenetwork_walk
network and configure a newnetwork_walk
mode in scoring, routing, and wherever else it is needed. Then the only remaining inconsistency seems to be the SRR issue from above.The text was updated successfully, but these errors were encountered: