Representing more detail

[dabreegster]

Today we have roads (individual lanes, each a thickened line-string) and intersections (a polygon, with each lane polygon meeting it at a right angle). That's a vast oversimplification. https://dabreegster.github.io/talks/map_model_v2/slides.html#/crossing-islands has some images of more situations, like...

• crossing islands / floating bus stops. Sometimes these are roughly linear along the road and could act like a thick sidewalk, but often the shape is weird
• lanes with variable thickness. "Pocket parking" doesn't just appear at a sharp right angle to the rest of the road; there's some kind of smooth curve in. And when turn lanes appear, it's gradual. Same for bulb-outs / curb bulbs.
• Advanced stop lines / bike boxes. The stop line for most vehicles is much farther back from the intersection, and the front is dedicated to smaller vehicles. Do we end the regular vehicle lanes early and count that as part of the intersection maybe?
• Modal filters. Sometimes these're defined as nodes / points in OSM on a way. Other times, the way gets split into a short segment with access restrictions marked. We probably need to normalize between these two and decide a representation.

@tordans, any opinions on representing these things? From my understanding of how strassenraumkarte works, you're working with geometry only, so there's no internal representation about these kinds of objects. With a stop line, you would just trim back roads appropriately and draw extra things. Right?

[dabreegster]

Notes from a call with @BudgieInWA...

Modal filters

Should we model these as a point along a road (the linear referencing model)? It has graph / routing implications, though. It would make more sense to introduce an intersection (with small size, not eating up much length of the road) where the filter is. That way, we can generate u-turns properly for vehicles.

Stop lines

Bike boxes, stop lines for vehicles, give way signs, separate traffic signals for bike lanes... all of these things can maybe be represented in the same way. A Road object could have extra stop line info for each end. In default cases, the stop line position is just at the end of each lane. Based on the intersection complexity classification and control type, the stop line could indicate a stop sign, give way, traffic signal.

But we can start reading more stuff from OSM to override the default. Some lanes might have a stop line trimmed farther back from the intersection (is this called "setback"?). The stop line has some vehicle restrictions, to indicate stuff like a bike / moped box at the front. Transit signal priority or bike-only traffic signals could be indicated here maybe.

There are complications... sometimes a lane continues straight/through without stopping, but if a vehicle is trying to turn, then there is an implicit stop line somewhere.

The stop line info + intersection classification will let us start drawing better detail in the middle of the intersection. On merges, lane markings continue through. Bike lanes crossing a side road are probably drawn dotted or something.

Small detail: do we need to represent just one distance / a point for the stop line? Or do we care about thickness of the stop line? Similar to the buffer/separator question in osm2lanes

OSM schema for protected signalized turns

On the incoming way, mark something like "left turn arrow / protected turn"?

To merge dual carriageways or not?

Problems like traffic signal timing get much easier with one consolidated intersection. They don't necessarily need dual carriageways to be physically merged into one object. Especially if the DC geometry isn't parallel and has some complexity that should be preserved, merging might not be desirable. Or if we need to relate back to original OSM objects. But the transformations that do the grouping and associate the pieces of the DC could still be useful. Or we want to do the DC merge, get the nice consolidated intersection, then undo the merge and just keep the nice intersection maybe.

Say we're doing the Streetmix-like editor on a dual carriageway. Then merging DCs seems nice. But even then, maybe it can be done "lazily" and to upload the changes back to OSM, we can still remember the two original OSM pieces and figure out how to distribute the lanes to each piece and update tags accordingly.

Crossings

For things like UK-style 2-part crossings with the island in the middle and maybe the zig-zag shape, that entire thing is maybe an intersection. The crossing is a turn/movement inside there, with some extra info to mark that there's an island in the middle to do it in two parts

[dabreegster]

Specific code changes that could happen immediately are #93 and #6