introduction of "router mode" (previously called mainMode) for (multi leg) trips

Description

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.

Why the routerMode information is useful

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:

  1. 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
      routerMode="cs_gasV"

    • home ==cs_walk==> cs_station ==eVeh==> shop ==eVeh==> cs_station ==cs_walk==> home
      routerMode="cs_eV"

    • The cs_walk occures in both subtours but the router need to handle that different (i.e. tolls for gasVeh)

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

Why it must not be called "mainMode"

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.

Open for discussion

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:

  1. adding the routerMode attribute also to these types of activities

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

Environment

None

Assignee

Unassigned

Reporter

MichaelA

Components

Priority

Major
Configure