Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

annotate trips with "routing mode" #738

Merged
merged 96 commits into from Dec 2, 2019
Merged

annotate trips with "routing mode" #738

merged 96 commits into from Dec 2, 2019

Conversation

@kainagel
Copy link
Contributor

kainagel commented Nov 23, 2019

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 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.

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.

vsp-gleich added 30 commits Oct 24, 2019
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
there is a bug with access walk legs having startLinkId null
TransitRouterWrapper, using the existing one as walkRouter!!!
vsp-gleich and others added 26 commits Nov 19, 2019
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
…ctivities happen at toNode)
formerly worked only for transit_walk
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! :-(
@kainagel kainagel merged commit b7a6b73 into master Dec 2, 2019
5 checks passed
5 checks passed
auto-merge Not merging
Details
Jenkins@VSP Build #1742 succeeded in 1 hr 49 min
Details
Summary 1 potential rule
Details
continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@kainagel kainagel deleted the routingMode5 branch Dec 2, 2019
@vsp-gleich

This comment has been minimized.

Copy link
Contributor

vsp-gleich commented Dec 2, 2019

See summary at https://matsim.atlassian.net/wiki/spaces/MATPUB/blog/2019/12/02/469270529/Routing+mode+helper+walk+modes

(copy):

We (Kai Nagel, Gregor Leich) just merged the branch routingMode5 into the development head master branch #738.

Summary:

  • all legs now have an attribute “routingMode”
  • the MainModeIdentifier is only used to retrofit old plans without routingMode (automatic in PrepareForSimImpl), it won’t be used in ModeStatsControlerListener (overwrite AnalysisMainModeIdentifier instead)
  • several helper walk modes such as “transit_walk”, “non_network_walk”, “access_walk”, “drt_walk”, “drt_fallback” were replaced by normal TransportMode.walk (automatic retrofit in PrepareForSimImpl), more precisely by calls to the RoutingModule for TransportMode.walk. This replaced many custom *walk routers and will allow routing “walk” over the network in the future.

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):

  1. to identify the correct routing module
  2. to identify the main mode according to transportation planning.
    One example where this becomes clear are the somewhat weird "main mode" definition in the German travel survey ... which just has an arbitrary hierarchy for multi-modal trips. So this varies from country to country, and maybe even from survey to survey.

We now split them up

  1. is now explictly saved in the attribute routingMode ( and uses MainModeIdentifier for retrofitting old plans)
  2. AnalysisMainModeIdentifier binding, defaults to routingMode for backwards compatibility, but can be overwritten separately from MainModeIdentifier with something more useful for mode share analysis.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.