Iterations may end up with many pure transit_walk trips

Description

Iterations may end up with many pure transit_walk trips.
By a "pure" trip I mean one that only consists of one leg, with this mode.
The pure transit_walk trips can be traced back to the transit router (TransitRouterImpl), which contains the following lines

So it returns a direct transit_walk if this is better than including a real transit leg.

This functionality was introduced to avoid non-sensical transit trips. They happen for example:

  • in areas without pt. The pt router then constructs a long walk to a pt stop, inserts a short pt leg, followed by another long walk to the final destination.

  • during times withouth pt. The pt router than constructs a walk to a pt stop where the agent waits a very long time for the pt vehicle.

The problem now seems to be that from the perspective of the transport planner, these pure transit_walk trips should just be normal walk trips. We are, however, a bit sceptic to just switch the mode (this would be easy, see the createDirectWalkList(...) method in TransitRouterImpl), since this would imply walk trips could be constructed without necessarily having them in the ChangeXxxMode specification. That is, a mode which looks the same from the perspective of the transport planner may look different from the perspective of the software.

Environment

None

Activity

Show:
Kai Nagel
August 29, 2016, 7:14 AM

Let's discuss it at the dev mtg. Conceptual meeting?

Kai Nagel
September 10, 2016, 4:10 PM

Discussed this a bit at the developer meeting. For the time being, this is the only mode where this happens. Introducing a "router mode" seems overkill in order to address this single instance.

Something similar could at some point happen when we have, say, bicycle access/egress to pt, where then also the whole trip could be done by pt. Then, however, we also will have to worry about, say, park-n-ride trips. We are not sure if a technical "router mode" will be the correct software solution for those types of problems.

Overall, therefore, strong tendency to live with what we have for the time being, and maybe bring up again in a couple of years.

There was a tendency to also report trip modes, and base this more on transport planning considerations. I just had, however, the first instance where this did not work well: Presumably, many of my pure transit_walk trips were in fact reported as "pt" in the survey but the transit router thought walking was better, so I really do not want to have them analyzed as walk. – ???

Marcel Rieser
August 28, 2018, 9:13 AM

DISCUSSION at DevMtg2018:

Currently, the router that generated a leg-sequence is somehow encoded in the leg-modes (“transit_walk”, “drt_walk”, …). Instead, it would be clearer to have for legs an identifier, which router generated them (“router-indicator”, aka “router-mode”).

It could be combined with the getting rid of the interaction activities and replacing them with WayPoints, which requires changes in the trip-detection infrastructure and population-file format as well.

Kai Nagel
August 28, 2018, 2:05 PM

Note that during my sabbatical I introduced

This will then internally use the travel time and the travel disutility of rm, but spit out the network mode as car.

Kai Nagel
December 12, 2019, 1:22 PM

Addressed with this here:

Assignee

Unassigned

Reporter

Kai Nagel

Labels

Epic Link

Components

Priority

Minor
Configure