BudgieInWA
commented
1 year ago I really like the idea of movements as an abstraction for working with these, while also enumerating the individual paths through the intersection, what you're calling "turns".
Sometimes 3 lanes lead to 2 and someone has to merge though. Or vice versa, one turn lane opens up onto 3 lanes, and there's a choice. Something has to say what turns are legal, and maybe prioritize them.
I think we should be opinionated in our assumptions. OSM has the ability to tag these explicitly using relations when something unexpected or ambiguous is happening, but there is a clear understanding that every driver comes to when they approach the intersection. That understanding is assumed and left untagged at the OSM level, and it is the understanding that we need to come to in order to understand these intersections, I think.
Stuff like, "don't change lanes in an intersection" practically means "allocate lanes in order, starting at the inside". We saw an example of the guide lines they paint when there is any ambiguity; they would put a single line between two adjacent turning lanes of traffic -- to keep them both in their lane -- to reinforce the "don't change lanes in an intersection" rule.
In fact, doing that with the northbound bus lane turning left or right, we see that we run out of destination lanes before we get to the bus lane. That tells us that the bus lane needs to merge into another lane while performing that turn. If you're merging, I guess you get to choose your lane, right? Maybe we should flag all turns that give priority while merging... Certain algorithms would love to ignore them.
dabreegster
mdejean
? Every lane hits the intersection at 90 degrees, but some lanes can extend farther in?
It feels like we're at a point to start figuring out how to represent turns / movements through intersections in osm2streets. (I've gone through this exercise before for A/B Street and made some questionable choices there, based on assumptions about how lane-changing should work in a traffic simulation. I'm viewing this as an opportunity to try again, with fresh eyes + experience + more discussion!)
How A/B Street does it: basic schema
A turn is uniquely identified as a (source lane, destination lane, intersection). The intersection seems redundant, but it's needed to talk about pedestrian movements. https://a-b-street.github.io/docs/tech/dev/formats/traffic_signals.html explains why.
Each turn has a type. For vehicles, it's straight / right / left / u-turn. There can be more nuance than that (5-way intersections, slight right). Distinguishing these types was partly helpful in writing heuristics to generate traffic signal configurations -- things like saying "at a 4-way intersection, the straight turns for the north & south roads can all go. The left turns have to yield." But defining these based on relative road angles was always brittle and hit edge cases, and I remember trying to come up with an alternate way to think about it... in a left-handed driving place, a left turn is one that conflicts with less turns than a right turn.
Turns conflict very "coarsely." A turn has a line-string of the movement through the intersection, and if those intersect, then they conflict. I think I've only needed the concept of conflicting turns in traffic signal configurations and traffic sim, but it may be a concept more widely useful.
Consequences
Defining turns at the lane level gets kind of weird.
Changing lanes in the middle of an intersection is illegal (I think in the US, possibly everywhere, whatever). But from this left lane, A/B Street has a straight turn going to either lane. I did it this way to avoid the absolute mess of simulating lane-changing, but it led to other problems in the simulation anyway. There has to be a way to penalize changing lanes like this, so by default vehicles only do it if necessary.
Sometimes 3 lanes lead to 2 and someone has to merge though. Or vice versa, one turn lane opens up onto 3 lanes, and there's a choice. Something has to say what turns are legal, and maybe prioritize them.
Lane types
Things get weirder with roads that have bus or bike lanes. A/B Street looks like this:
A bus in the right lane can turn left, cutting across a bunch of lanes. This is incorrect here and maybe in many cases, but... not always. Sometimes there are traffic signals configured to let bikes or buses start first and possibly do weird movements like this.
Movements
At some point, working at the lane granularity got really hard for traffic signals. It was better to think about the entire "directed road segment" -- aka a bundle of lanes pointed the same way. A movement was defined at this higher level, and it bundled together some turns. It looks like this:
https://user-images.githubusercontent.com/1664407/184869795-376d2be1-4b9a-4cae-b314-49965d5b6550.mp4
These probably need to be refined to talk about just the bus or bike movements too, in some cases.
How this is all generated
Messily! https://github.com/a-b-street/abstreet/blob/master/map_model/src/make/turns.rs does roughly this:
1) Look at every source and destination lane at an intersection, create a turn linking them 2) Do some bezier curve magic by Marcel to create geometry 3) Classify into straight/left/right/u-turn 4) Attempt to filter out turns based on different types of turn restrictions. Sometimes that process breaks, so the logic is complicated -- it'll give up on filtering and just keep the original things, instead of "orphaning" a lane. Every lane should lead somewhere, and should be reachable from somewhere.
There are 3 types of turn restrictions. 1) "Simple" ones are relations between OSM ways. Allow or ban turns from road1 to road2 2) "Complex" ones are relations involving multiple OSM ways. I only supported one "intermediate" way, but meant to support more. I can pull up some examples somewhere, but these're used for things like U-turns in complex intersections / dual carriageways. The consequences of these at a routing level is quite complex -- you have to replace part of the graph with "uber-turns" that describe a sequence of movements. 3) Lane-level restrictions. Once we know road1 can go to road2, specifically what lanes can do what?
Pedestrian movements
Most of the above is about vehicle turns. Pedestrians have "crosswalks" and "unmarked crossings" through intersections, the latter of which isn't well supported. Those're meant to be the difference between explicit zebra crossing type things, and movements which are not physically signed but are either legal or definitely performed in practice.
There's also "shared sidewalk corners" for lack of a better term, where the pavement extends through the intersection and doesn't cross any other turn.
Testing
Done very poorly in A/B Street right now. Aside from the interactive turn explorer UI shown in some screenshots above, I have some snapshot tests recording all the generated turns for a few test cases, and I can tell when a code change modifies these. Then I'd use the UI and manually look.
So now what?
There's lots above, and it doesn't even cover things like conditional restrictions (no turns during peak hours, except for buses). Anybody have thoughts about what we should do for osm2streets or how to proceed?