🪲 Model network creation doesn't handle ML when road switches to one-way (medians)

[lmz]

Describe the bug

Right now, if there is a section of roadway with a managed lane (say, bus lanes) and there's one section with two-way links (no median) and then it splits, the handling of the new ML nodes doesn't work...

In the above screenshot, the blue links are the original links and you can see they switch to one-way for a period. But (I think) the algorithm creates a unique ML node for each GP node, and so I got errors that the nodes were being created twice, but with different coordinates.

I started to try to fix that by averaging the node coordinates but it doesn't make sense... in this case, the offset means there would be two ML nodes for one-way links and one ML node for two-way links. In theory we could leave the links this way and fix with connectors...

Thoughts on resolution

ML links may need to always be one-way?
Either that or handle this case explicitly, which seems messier to me.

To Reproduce

Failing tests

• No applicable test failed, need to create.
• [ ]

Triggering line of code

Full stack trace

Environment

Operating system:
Context (conda, jupyter, etc):
Environment (e.g. output from conda list):

[DavidOry]

I vote for the resolution of changing the definition of "managed lane" in network-wrangler to be the following: "Lane-specific access restrictions for automobiles on a multi-lane, one-way road, such as a high-occupancy vehicle (HOV) lane or a high-occupancy toll (HOT) lane".

In these cases, network-wrangler will draw a parallel network link that can be configured to allow for access restrictions. Users can then assign prices or occupancy rules on these links independent of the general purpose lanes. The numbering is done such that in a post process, the automobile volumes on the managed lane link can be added back into the volumes on the general purpose lanes.

If we go forward with this definition, then the code should identify @lmz's request and throw an error. Something like: ERROR: Managed Lanes can only be applied to one-way roadways.

My rational is as follows:

• This functionality should not be used for physical infrastructure. For example, if a two-lane busway were added to the median of a roadway, the "travel modelly" way to address this would be to add a dedicated transit link, just as we would for a railway. The bus could then traverse the link at a fixed speed independent of roadway congestion. Another example would be a shared lane that changes direction, like in the Golden Gate Bridge, or I-394 in Minneapolis, or center turn lanes used as travel lanes in peak periods in Phoenix and Tucson. The best way to address this use case is by changing the number of lanes by time of day.
• A narrow definition of managed lanes allows the code to be focused and simpler.
• My proposed, narrow definition likely addresses nearly every use case. I'm sure there's an edge case that may motivate a broader definition, but let's wait until that comes up rather than try to anticipate it now.

What do you think @lmz?

[lmz]

I think that proposal makes sense, @DavidOry. Does that work for you, @e-lo, @RachelWikenMC, @i-am-sijia? (Anyone else who would have an opinion about this?)

[RachelWikenMC]

I'm fine with Dave's suggestion. We are only tolling on highways, which are one way links. This hasn't been an issue for us. The 394 managed lane already exists in our network as a physical link, so we added tolling info to the connection links. That seems to be working.