Discuss ways to merge separately mapped sidewalks and bike lanes about osm2streets HOT 7 CLOSED

Thank you! Great issue.

I've faced this problem a couple of times. We can certainly add multiple way processing, but I'm not sure how to identify them in the first place. As you mentioned, probably all the approaches are error-prone.

from osm2streets.

I've attempted this before, #59 tells the full story. Some of the problems are #59.

But I did make some headway on this -- https://github.com/a-b-street/abstreet/blob/master/map_model/src/make/snappy.rs for reference. This code only tries to deal with merging separate cycleways with the main road. As a first pass, it only looks at ways with separation:left|right (https://wiki.openstreetmap.org/wiki/Proposed_features/cycleway:separation). Partly this helps us know which direction to search and partly this was a way for me to slowly "opt in" some cycleways around Seattle into the experimental merging, by filling out the tag.

Walking through how it works...

1. Find the center-line and estimated width of every separate cycleway
2. Create a quadtree (spatial partitioning structure that can quickly answer questions like "what's nearby") containing all of the left and right edge of every "regular" road segment
3. Look for matches
4. Delete any way that was snapped, and insert the lanes (and separators) into the main road

I have a few different ideas for how to look for matches. The thing currently implemented steps every 5 meters along a cycleway, projects a perpendicular test line 3 meters from the left or right edge (based on the separation tags), and looks for the nearest collision with one of the main road edges. Based on problems I hit, the match also has to have the same layer (z-ordering). And I was also requiring the cyclepath and main road to have a similar angle where the perpendicular line connects them -- within 30 degrees.

One of the biggest complications is when the main road or the cycleway are chopped up into different pieces. Around some intersections in Seattle where I was testing, some of the curb cuts are micro-mapped, so there will be tiny cycleway segments at a bunch of different angles. https://www.openstreetmap.org/way/835195091 is a simpler example of that. The current snapping code requires at least 80% of the cycleway to snap to some roads (maybe multiple). An example where this is tricky is the Burke Gilman trail at https://www.openstreetmap.org/node/53108420#map=19/47.66568/-122.30189. It's mostly a separate trail, but around here, it physically joins up and becomes part of the sidewalk on NE Blakeley Street:

(The screenshot is without any snapping)

Sometimes we might have to logically split a longer main road's way to indicate where a cyclepath runs parallel to it or not.

These're just some of the problems I hit. Many might be specific to a certain area.

from osm2streets.

AFAIK there is no way to solve this in JavaScipt/Node. But it is possible to solve it in QGIS and likely the underlying Python libraries.

If we can get a robust approach working using any language/dependencies, it's definitely possible to get it working everywhere. If GDAL or Shapely or libraries in some language make it easy to come up with good heuristics, then we can adapt the approach elsewhere

from osm2streets.

I feel like this should be beyond the scope of osm2lanes because it involves spatial reasoning. (Probably any problem involving multiple osm ways will end up needing some).

There are some great insights in this thread, and I would like to add that the calculated or estimated width that osm2lanes produces would be an valuable input into any algorithm that was able to do this snapping. It might even be useful to be able to request "minimum sensible" "likely" or "maximum sensible" estimated widths from osm2lanes.

from osm2streets.

Now that we are in osm2streets, lets look at ideas for achieving snapping.

One perspective is that of the planar coughz-indexcough graph. When snapping occurs, we are removing a little region in the graph. If we look at the geometry of the regions in the graph, we might be able to recognise medians and verges and thin barriers and stuff, by their characteristics.

from osm2streets.

That's a neat idea. I've done some work in tracing polygons "around the block" that could be lifted to the RawMap layer, and it usually picks up the spaces in between dual carriageways at least:

You could play with this by going to http://play.abstreet.org/0.3.21/abstreet.html?--dev&system/us/seattle/maps/phinney.bin&--cam=17.89/47.68380/-122.34385, pressing ctrl+D for debug mode, then ctrl+B for the blockfinder. This process breaks down when the separate ways are so close together that their inferred width causes the two polygons to overlap, though.

from osm2streets.

I made recent progress in #61. Projecting perpendicular lines is tricky business for many reasons mentioned above. I tried a new graph-based approach. The parallel cycleway will be connected to the main road at some point -- probably when it crosses side roads. So this transformation uses that, but still uses geometry to figure out left/right.

I'll keep iterating on this particular transformation to make it work more robustly. Then I don't see any reason why we can't also try to apply it to sidewalks...

from osm2streets.