Turns / movements about osm2streets HOT 13 CLOSED

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.

from osm2streets.

The term Manoeuvre came to mind. Is that a specific turn? "from the bus lane on the right, left turn into lane 1"

from osm2streets.

I noticed this at an intersection the other day: This set of lights has helpful turn guides marked on it, including a diamond (painted in "road edge" style) right in the middle, where no turn paths cross. There was a collection of bluestone gravel from construction that has collected, and remained undisturbed in the centre of the road, showing how accurate the markings are! You can see all of the turn paths that I would expect anyone to make through that intersection (even making assumptions based on the lack of turn arrows in the two main lanes. I guess the left lane turning left without an arrow is always an option they have, and never an option anyone else ever has...).

See how it predicts exactly what the intersection looks like? And that island in the middle of the OSM "#" has a large enough area that rocks can collect, so maybe it's big enough to spawn a buffer area with edge markings. Much bigger and you would consider putting a traffic island in there...

If we can consolidate these intersections through whichever transformations are easiest, then generate some sort of turn paths (starting at some sensible location, maybe the stop line, or some guessed setback from the intersection), that would be awesome. Maybe all the optional turn paths are included at first, until some transformation makes a guess at what the legal turn paths are.

(I am interested in seeing what we can interpret from the shapes of the turns too. You usually get pointed directly at your exit lane for "through" manoeuvres, e.g.)

from osm2streets.

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.

Agreed, we should algorithmically generate this and also handle when it's tagged explicitly. https://github.com/a-b-street/abstreet/blob/a791a5cca754ff9ec3a07b1270865ec7cfa171cc/map_model/src/make/turns.rs#L308 is my attempt at the first thing. I don't offhand remember the tag used for the second.

If we can consolidate these intersections through whichever transformations are easiest, then generate some sort of turn paths

Indeed interesting how turn paths and the intersection geometry can both influence each other a bit. Right now the turn path uses the set-backs calculated by the intersection polygon algorithm. The turn path is here, written by @mdejean. There are cases when the turn path "leaks outside" of the intersection polygon -- I can't find any offhand right now, but I think it happens with really narrow service roads.

The images and idea of tracing where cars go reminds me of https://en.wikipedia.org/wiki/Sneckdown

from osm2streets.

from osm2streets.

eliminate the 'all lanes of a road are the same length' rule

Curious what you mean here (because it might also be a good time to re-evaluate this assumption). Something like ? Every lane hits the intersection at 90 degrees, but some lanes can extend farther in?

from osm2streets.

Something I picked up looking at the JOSM Lanes plugin implementation, is a way of representing these angled "end caps" for roads like the "miter" joins between road segments.

The desired road/lane end angle (where the stop line is often found) is just like the line of reflection that would be found running through a miter, if the road continued along the grey markings. Perhaps these "angled end caps" should be implemented as a capability of our "thick line strings". Seen angStart and angEnd arguments in getParallel

Lanes on the outside of turns already have a longer length, so we might have to look at individual lane lengths at some point anyway...

from osm2streets.

I see, this gets rid of the assumption that the road hits the intersection at 90 degrees, without doing something silly like the jagged teeth of https://a-b-street.github.io/docs/tech/map/geometry/index.html#desired-output. I'm in favor of trying this out!

It indeed sounds like we need more state per lane. It shouldn't be too crazy a change downstream... already there are methods to get the center line of each lane

from osm2streets.

I have had a crack at calculating turns through an intersection in the street_network crate, and also tried to detect MultiConnection intersections, which was interesting.

Instead of starting with the lane-specific turn paths being calculated and grouped into movements, I feel like the valid movements should be calculated first, and turn paths can come a bit later in the process. This is because way-to-way routability is critical in understanding what type of intersection we are working with (e.g. for deciding which pieces of OSM geometry are non-sense in sausage links). OSM tries really hard to make it clear what the routability through an intersection is at the way-level, but the lane-level stuff is underdeveloped. Then maybe the individual turn geometry will be useful in the later stages for making tweaks (like rounding the corners, adjust the setbacks etc.)

For example, an intersection with a two-way road and two one-way roads could be a "sausage link" where a dual carriageway joins back up, or it could be a side road on a one-way road. It all depends on if you are able to travel from the inward one-way road to the outward one-way road or not. Some mappers would put a "no u-turn" relation in the dual carriageway case, but there is advice out there that it is not needed and that data consumers will figure it out -- which we should be able to learn from those who have implemented OSM routing engines.

If we can represent movements right at the core of our Intersection type (preserving them through merges) and calculate them from raw OSM and simple heuristics up front (without needing much context), I think we will be a whole lot closer to intersection road markings and the like.

from osm2streets.

So if I'm understanding correctly, the idea is to work at the movement (direction + road segment) level as long as possible, then make specific turns (lane-level) later? We first generate all possibilities and filter using turn restriction relations, and maintain those through transformations? In your turn paths branch, you're working at the lane level. I'm not sure which approach is appropriate yet or not, just trying to follow the idea

from osm2streets.

Yes, I would like to see how far through the process we can get before lane-level turns become needed. The turn-paths branch is where I decided this: I was trying to generate only valid turns (that don't change lanes through an intersection, etc.) which is a complicated problem itself that wants to know what movements are valid to begin with. I started down the path of calculating the geom for the turns right away, but a lot of that stuff lives in an abstraction a layer or two above. The turns seemed useful even without geom, but movements are a better fit I think.

from osm2streets.

Got it, so the overall flow is something like...

1. Generate all possible movements between directed roads
2. Filter based on turn restriction relations, and maybe inferred U-turn cases
3. Classify intersection complexity here (or maybe later?)
4. Generate lane-level turns, using turn lane tagging and heuristics about which lanes have to merge with each other

Once we get some of the concepts/terminology settled a bit, we could start wiring this up in the UI and record test data for it, to make iterating faster

from osm2streets.

That sounds about right. Maybe it will be best to merge certain intersections (like dual carriageway # intersections) before trying to figure out the movement, but maybe not.

At step 3, I'll try to classify complexity, but also detect road pairs that continue through the intersection uninterrupted, and other "features" of the intersection that can't be captured by a single enum. These features effect the intersection geometry which lets us straighten out sausage links, for example.

A debug visualisation of movements will be useful as soon as movements are represented, I think. Even straight lines connecting the ends of the trimmed centerlines of the relevant roads should be a good start.

from osm2streets.