We recommend to introduce the routerMode attribute to legs to define what the previously called "mainMode" is for routing. NOTE: it must not be called "mainMode" since it is an internal information for the router and NOT the transport planning definition of a main mode.
The definition what a mainMode for a multi-leg trips is or should be is vague and focused on pt trips only, i.e. a trip containing a transit_walk leg or a pt_interaction activity is assigned hard coded as pt mainMode.
But this tripple (leg mode, trip activity type ==> main mode) cannot be extended to general usages. Examples are:
car sharing (CS): difference between a CS gasVeh trips and CS eVeh trips
home ==cs_walk==> cs_station ==gasVeh==> shop ==gasVeh==> cs_station ==cs_walk==> home
home ==cs_walk==> cs_station ==eVeh==> shop ==eVeh==> cs_station ==cs_walk==> home
The cs_walk occures in both subtours but the router need to handle that different (i.e. tolls for gasVeh)
multimodal trips: different walk trips between the different tranport modes used
home ==walk==> pt_station ==pt==> pt_station ==walk==> cs_station ==cs==> shop
Here, the middle walk leg cannot clearly assigned to either PT or CS.
Therefore, the routerMode information would clearly define what kind of router (cs_gasV-, cs_eV- or pt_cs_multimode-router) should be used to calculate multi-leg trips.
The routerMode information is a MATSim internal information for using the right router rather than a transport planning "main mode" definition. It is up to the user how analyses the MATSim results how he/she wants to aggregate multi modal trips to main modes. The third example (CS and PT) shows that nicely. For the transport planning perspective there is not yet any definition what the main mode of a pt-cs-multimodal trip is. So, MATSim should not predefine that.
The identification what activities are part of a trip has to be told the specific routes at the moment. This still works with the routerMode but it could be done different, too:
adding the routerMode attribute also to these types of activities
introduction of the <trip> XML element that contain the leg-act-leg-act-...-leg sequence. In that case the routerMode can be defined as trip attribute.
We should probably discuss this face-to-face to better see the use case, but I deliberately did not include "mainMode" attributes when designing the new routing infrastructure. The idea was that a park-and-ride trip, for instance, is composed of a car leg and a PT trip, both being "routable" by the classic car and pt routers.
This is the reason why the trip router can be provided custom "activityTypes" objects.
Another way to interpret the attribute would be to say that it identifies the router which actually computed the route.
And we deliberately did not include the trip xml element
This functionality needs to programmed out explicitly in MainModeIdentifier. There need to be two different versions of this for
to identify the correct routing module
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 eventually came back to this and introduced an attribute "routingMode" at legs PullRequest738.
to identify the correct routing module -> TripStructureUtils.identifyMainMode()
to identify the main mode according to transportation planning -> AnalysisMainModeIdentifier interface (defaults to the routing mode identifier above so results are similar to before the introduction of routing mode)
wow, issue #26, more than 7 years old, gets resolved! Thanks for your work, Gregor!