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):
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.
streets GL notes
https://github.com/StrandedKitty/streets-gl/blob/dev/src/lib/road-graph/IntersectionPolygonBuilder.ts looks familiar, but the code feels simpler than https://github.com/a-b-street/osm2streets/blob/main/osm2streets/src/geometry/general_case.rs.
https://github.com/StrandedKitty/streets-gl/blob/dev/src/lib/tile-processing/vector/qualifiers/factories/osm/OSMPolylineQualifierFactory.ts is the Muv/osm2lanes equivalent. Looks like some built-in lane width estimates.
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.
... 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?