Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
annotate trips with "routing mode" #738
This is still failing one or the other test, but I think that we will be able to fix this during the week and then we would like to merge this, because it has a tendency to cause conflicts with dvrp/drt.
The content is our long-discussed "routing mode", i.e. that trips memorize the router from which they were generated. The prime example is a trip which currently may have mode
In general, we are not using
The implementation currently is via
Most of the work was done by @vsp-gleich (thanks a lot, Gregor, I know that this was quite involved). I am just writing this here because he is on vacation, and I want to move this forward in a way that we can merge a small number of days after his return.
PrepareForSimImpl is run only once before simulation starts, this cleaner and faster than having it in PersonPrepareForSim which is run in every iteration (and thereby might hide problems in Replanning modules still creating outdated plans)
TripRouter will add attribute routingMode instead TODO: replace with call to FallbackRoutingModule
Conflicts: contribs/drt/src/main/java/org/matsim/contrib/drt/routing/DrtRoutingModule.java contribs/drt/src/main/java/org/matsim/contrib/drt/run/DrtModeModule.java contribs/drt/src/test/java/org/matsim/contrib/drt/routing/DrtRoutingModuleTest.java contribs/dvrp/src/main/java/org/matsim/contrib/dynagent/run/DynRoutingModule.java matsim/src/main/java/org/matsim/core/router/FallbackRoutingModuleDefaultImpl.java matsim/src/main/java/org/matsim/core/router/NetworkRoutingInclAccessEgressModule.java matsim/src/main/java/org/matsim/core/router/RoutingModeMainModeIdentifier.java
old injected MainModeIdentifier is used only for retrofitting outdated plans at start up. After retrofitting it returns wrong results for ModeStatsControlerListener. Effectively that also means that the MainModeIdentifier in ModeStatsControlerListener can no longer be overwritten! :-(
We (Kai Nagel, Gregor Leich) just merged the branch routingMode5 into the development head master branch #738.
This is a pretty old topic (MATSIM-26: introduction of "router mode" (previously called mainMode) for (multi leg) trips), partly solves several Jira issues, e.g. (MATSIM-943: do not use pure transit walk, pure drt walk, ..., MATSIM-856: Population V7, MATSIM-473: Iterations may end up with many pure transit_walk trips) and makes life easier for intermodal trips.
The content is our long-discussed "routing mode", i.e. that trips memorize the router from which they were generated. The prime example is a trip which currently may have mode transit_walk; in the future, it would have mode "walk" and routing mode "pt". This also means that "MainModeIdentifier" will no longer be necessary. (We will keep it to retrofit older plans files.)
In general, we are not using non_network_walk or transit_walk or drt_walk. The reasoning is that teleported bicycle is bike, not non_network_bike, and we have always done it like that. In consequence, if the walk router called from, say, the pt router is a teleportation router, it will still return plain walk. The only exception is a network-based walk router: In that case, we indeed have non_network_walk access to the walk network, then a walk leg along the network, and a non_network_walk to the final destination.
The implementation currently is via Attributable. Since there is no trip, we attach it to every leg. Trips that have inconsistent routing modes in their legs will lead to an error. We should probably consider to elevate the routing mode to a typed argument with a future population file.
“non_network_walk“ will now only be used by the walk router if walk is routed over the network and only for access/egress to the walk network. It is some kind of fallback layer to access the network. All other modes can use the walk router to access the network. Per default the walk router is still a pure teleportation router NOT routing over the network. So in the end what was a non_network_walk → pt interaction → pt → pt interaction → non_network_walk trip will now per default be a walk → pt interaction → pt → pt interaction → walk trip with the plansCalcRoute and scoring parameters of walk!.
Keep in mind that what was previously a direct walk “transit_walk” is now a walk leg with routingMode pt and has the same scoring and plansCalcRoute parameters as walk with routingMode walk, so mode shift from one to the other does not necessarily mean a real change (that problem already existed before as the default for transit_walk was to copy parameters from walk). Similar issues apply to the other fallback modes (drt_walk, drt_fallback). Previously we had only the MainModeIdentifier which was used for two rather incompatible purposes (see
MATSIM-26: introduction of "router mode" (previously called mainMode) for (multi leg) tripsDone for details):
We now split them up
This is only an analysis problem, you can now plug in an AnalysisMainModeIdentifier to fix this in analysis, e.g. overwrite the default with an hierachical MainModeIdentifier such as TransportPlanningMainModeIdentifier.