Prioritization exercise: make one area "perfect"

[dabreegster]

As a sort of thought experiment, I want to consider what it would take to really polish one place in osm2streets. But even more, to motivate pushing more responsibility from A/B Street into here, I'll use current A/B Street rendering for judgment. Picking somewhere in the world uniformly at random, let's have a look around Kennington, London.

The list below is definitely not exhaustive, but for sure carves out plenty of work.

Bike boxes / advanced stop lines

https://www.openstreetmap.org/node/8958613758

We don't attempt these at all yet. Vehicles stop at the southern traffic signal node (the position of the node defines the stop line!). Cycles stop a bit farther up, at the cycleway=asl node. We could draw the bike box markings from this.

Some concepts to think about representing: explicit stop lines per vehicle type. How should that affect the intersection geometry?

Using shared sidewalk corner rendering code

There's an absolutely tiny segment showing contraflow cycling near https://www.openstreetmap.org/node/9063135167#map=19/51.49191/-0.09975. The geometry we produce is not ideal, but it's OK. A/B Street is still using older code for drawing corners between sidewalks, and it blows up here:

If we start representing movements (or maybe the lane-level equivalent) between specific sidewalk lanes in osm2streets, I'd love to cut over to it. I think the big API mistake in A/B Street to re-think is whether some movements have any PolyLine geometry at all. When the intersection geometry is messed up or the trim is super tiny, maybe there's no geometry at all. We can still semantically handle it.

Dog-leg intersections

I just ripped out the dog-leg code because I've been trusting this "road getting trimmed into oblivion" logic so much, but https://a-b-street.github.io/osm2streets/#20.696807407887984/51.49212/-0.10287:

Stop signs

I've seen approximately 3 stop signs in the UK so far. In cases where a minor road hits a major road, there are usually give way markings instead. So, two changes to think about. First, explicitly calculating priority/precedence between roads at an IntersectionControl::Uncontrolled or Signed intersection, usually with heuristics but sometimes with explicit sign nodes. And second, introducing some region-specific rendering for markings.

Crosswalks

Above screenshot also shows zebra crossings everywhere. We should start incorporating footway=crossing ways like https://www.openstreetmap.org/way/1109040580. A/B Street has a very weak concept of marked and unmarked crossings right now. We should figure out what we want to do in osm2streets, and also how crossings defined in OSM should affect intersection geometry / road trim. And more region-specific markings, UK zebras have a zig-zag pattern on the road within X meters of a zebra, and also flashing light post things.

Note explicitly mapped crossings often connect to explicitly mapped sidewalks, but I'm not proposing to try and handle those yet. Coverage around Kennington is spotty, and I still consider solving this generally to be one of the hardest problems in osm2streets. We can make progress anyway though.

Contraflow cycleways

https://www.openstreetmap.org/#map=19/51.48516/-0.11547

There are many variations of these everywhere. Some simple cases could maybe use the existing sausage link logic?

Parallel cycletracks

https://www.openstreetmap.org/#map=19/51.48547/-0.12067

Can the current experimental transformation be used here? What's blocking us from enabling it in general?

[BudgieInWA]

If I understand the new algorithm correctly, this breaks because the short middle road is not trimmed by either intersection. When calculating the left intersection, the short road is just short enough to avoid having its edge line (thin green) intersect with the long road's edge line (thin blue) - as shown expanded in the circle.

I think this could be solved by extending the far end of the roads if needed to get an intersection between the edges. This corresponds to the dotted green line. This would result in a positive trim distance that is longer than the road itself, so the short road would be marked as internal after looking at just one of the Intersections.

I think this is the same problem:

[dabreegster]

I think this could be solved by extending the far end of the roads if needed to get an intersection between the edges.

Hmm, you're right. #149 was an attempt at this. Worth trying again now that we have both sides working off untrimmed geometry properly now

[BudgieInWA]

If the area to prioritise is large enough, we quickly end up needing to support the majority of the complexities that osm2streets needs to support before the area is "perfect". So I don't think this will serve as a useful prioritisation tool in the medium term, but this exercise has raised some useful specific examples to resolve.

Maybe we ought to have a "roadmap" meeting now that the dust is settling from the recent refactors. I think it would be valuable to identify the distinct road features/complexities that osm2streets doesn't represent yet, and make an educated guess at how they might fit together, and what the dependencies between them are.

[dabreegster]

Agreed, maybe prioritisation exercise wasn't the right concept. A roadmap meeting would be perfect -- the usual time any day this week is good for me.

An unorganized jumble of some of the items there:

• TrafficInterruption per lane (or vehicle type)
• TrafficInterruption summary per road
• inferring those from whatever we have now, and also bringing in explicit OSM tags
• rendering the above (maybe first picking UK or Australia's style always, then later with localisation)
• Per movement geometry, lane-level movements
  • a StreetExplorer tool to draw more detailed movements when you hover on a lane, for easier debugging
• continuing lane markings through movements