a-b-street/osm2streets

Fail less often for intersection geometry

Opened this issue · 4 comments

Especially when we use raw OSM footways, we break on so many intersection geometry cases (the circles):
image

I'll start looking into these, but I've also been looking at how https://github.com/StrandedKitty/streets-gl handles things. It's much more robust.

TODO:

  • Can we have an optional mode where we don't trim back road center-lines at all and have empty intersection polygons, just to debug and see how it looks?
  • Investigate what streets-gl does and see if we can adapt ideas from it

CC @BudgieInWA in case you're interested or have ideas. osm2streets has revived thanks to the Muv work. I'm kind of interested in getting footways and crossings all showing up exactly as they're in OSM, and generally getting rid of the old inferred sidewalks mode.

Many of the problems are happening at degenerate intersections, with exactly 2 edges. There's a hardcoded length we demand to trim roads back. The Aurora example fails because the footways are split into tiny pieces to show curb cuts, so I tried reducing this distance a bunch. Doing better, but looking carefully at the polygons shows overlapping bits, so I'll keep looking at it.
image

Ah actually much of the noise was the sidewalk-corner markings being applied when they shouldn't. But still a few "bow-tie" cases with the degenerate intersection geometry that could be improved,
image

... but also regressions with fixed 0.1 meter, by https://www.openstreetmap.org/node/2918402990. Maybe the relative thickness/angle of the two roads needs to matter. Do we need this hardcoded param at all? Can we just make a triangle or quadrilateral generically?