Force Transit Boarding in Path Builder (i.e., prohibit walk-all-the-way paths) #143
Conversation
| transition_rules_walk.extend( | ||
| [ | ||
| { | ||
| "mode": "e", |
There was a problem hiding this comment.
Thanks @yueshuaing. One question: why do we need mode e in journey level 0? Isn't this journey just to get us to transit? I suppose the e links will not be used because destinations_reachable is set to False. But I want to make sure I'm not misunderstanding something.
There was a problem hiding this comment.
Every level will have all the transit and auxiliary modes. If a value of a mode isn't specified, it will default to the current level, I guess it's still 0. But we can check the run log to confirm.
There was a problem hiding this comment.
we could also create a new journey level to prohibit e in level 0.
DavidOry
changed the title
| @@ -2231,13 +2231,41 @@ def _journey_levels(self) -> EmmeTransitJourneyLevelSpec: | |||
|
|
|||
| elif self.name == "WLK_TRN_WLK": | |||
| new_journey_levels = copy.deepcopy(journey_levels) | |||
There was a problem hiding this comment.
Adding some annotation of the changes. The journey_levels is a list of dictionaries, with each dictionary defining a journey level. Due to the complexity of the fare system, the journey_levels (or states) are specific to different fares-paid states, which are created programmatically. (In Task Order 5, the programmatic approach will replaced with something simpler).
What's being done in the below code snippet is adding a journey level. This state will be walking prior to boarding. As a first step, we are, for each journey level, adding the ability to transition to all the existing states (i.e., I can go from the walking prior to boarding state to each of the transit states).
fyi @lmz, @FlaviaTsang
| }, | ||
| {"mode": "a", "next_journey_level": 0}, | ||
| ] | ||
| ) | ||
| new_journey_levels.insert( |
There was a problem hiding this comment.
At this point we have updated the journey_level list to include a new journey_level 0 and allowed the ability to transition out of this state to any of the other states. Now we want to attribute the the level 0 state. The key attribute is destinations_reachable set to False. This disallows walk-all-the-way, as you have to transition out of this state to reach your destination. To transition out of the state, you need to board a transit vehicle. The transition_rules, which are defined above, define what happens when a traveler goes from their existing mode to w, a, or e (walk auxiliary, walk access, or walk egress), which is they remain in state 0. Again, to get you of state 0, you must board a transit vehicle and enter one of the other states.
fyi @lmz, @FlaviaTsang
|
@AshishKuls: bringing this in to our working branch. |
|
@DavidOry I think you closed the PR without merging. |
What existing problem does the pull request solve and why should we include it?
The current transit assignment procedures allow movements to walk all the way from origin to destination. On the one hand, this is desirable, as walking all the way is often the lowest "cost" path. Forcing paths that include transit may result in unrealistic paths that will be hard for the mode choice model to completely eliminate. On the other hand, the point of the transit path builder is to create transit paths, not walks paths. An assignment of the on-board survey revealed that about 20 percent of the observed transit movements were given a walk-all-the-way path in the version 2.2.2 (version 1) configuration. We therefore want to test the impact of forcing a transit boarding in the path builder configuration.
What is the testing plan?
As part of the on-board assignment path builder calibration (see #142), we will document the impact of this on the outcomes. Software changes are minimal and difficult to test outside empirical validation.
Code formatting
Code should be PEP8 compliant before merging by running a package like
black