Open dabreegster opened 8 months ago
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.
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,
... 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?
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:
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.