a-b-street/abstreet

Blocks are badly extracted

TFCx opened this issue · 9 comments

TFCx commented

I'm trying to evaluate A/B Street and LTN for my pro-bike association in Montpellier, France.

When analyzing Montpellier, it seems that the algorithm that extract blocks can create polygonal shapes that have auto-intersections as well as having into one single block, several disconnected cells.

In the following example, the dark blue zone is one single block.

image

If i'm looking at the whole city, there are several similar problems (another example is that the city center is considered as one block, another problem is a residential district that is part of no block whatsoever).

I've quickly looked at the OSM data but I didn't find any obvious problem that could be the cause.

Are there manual tools to redelimit the different blocks? Or does the extracting only exist as an automatic procedure? How can I help to fix this problem?

Thank you for all the hard work done on A/B street. It's a project i've been following for years... yet i've only started to experiment with it this week :).

dabreegster commented

If you want to dig into why this process fails, open the same map in the main A/B Street tool (sandbox mode from the title screen). Enable dev mode with Ctrl+S, then debug mode Ctrl+D, then the "blockfinder" Ctrl+B. Let's look at the broken area:

screencast.mp4

Things go wrong by https://www.openstreetmap.org/way/31340641#map=19/43.59740/3.88717, where there's a bridge. This is a very common problem in the LTN tool -- #857 and #1024 for more context. There's no problem with the OSM data.

Are there manual tools to redelimit the different blocks?

You can "Adjust boundary" once clicking a neighbourhood, but that still works block-by-block. If the automatically found blocks are broken, there's nothing you can do right now, unfortunately.

I think the fix for this particular area has to be for blockfinding to understand bridges/tunnels, and treat the point where roads cross as an intersection, to force the resulting blocks to form a planar graph. This is not easy (I've been trying on and off since Dec 2021!), and I unfortunately don't think I'll have time in the near-term to try again.

Another wildly different idea for letting you specify neighbourhood boundaries is to draw a snapped "route" along the boundary. I recently implemented this in another project -- go to https://acteng.github.io/atip/scheme.html?authority=West%20of%20England%20Combined%20Authority#9.86/51.476/-2.513, then try the "New polygon (snapped)" tool. It's maybe worth implementing the same control in the LTN tool. That tool also just works off of a simple graph with nodes and edges, so we'd have to make the OSM graph planar where bridges/tunnels cross. I've also played around with mapshaper and topojson for doing this kind of thing. If we go this route, we have to turn a raw polygon into a sequence of roads that the LTN tool understands, with some kind of map matching or simple polygon overlap -- see #995 for some ideas there.

CC @andrewphilipsmith as more context on ongoing work with the LTN tool

TFCx commented

Thanks for the infos :

  • there seems to be a different problem for the small black on the left. How does A/B street map understand that there is some kind of road maintenance there? The OSM nodes don't seem to reflect that. (Note that there are currently some road blocks there).

image
image

  • Have you considered to remove the bridges/tunnels edges from the graph, transforming them into virtual deadends for the blockfinder algorithm? And re-adding them later when blocks are defined? It might be a naive idea you've already explored.

  • Also, have you also considered iterating on all edges (even non-car edges)? Or is it too costly performance wise? Some blocks, especially near rivers, aren't taken into account ; yet are completly enclosed. Those blocks could then be merged together until some border is a car street.

  • Finally, do the triangulation always work with simple or weakly simple polygons? Those large triangles overlapping the whole district are a bit distracting and it seems some are produced even with planar blocks (?). But I agree that 90% of them are produced thanks to tunnels/bridges :(

Thanks you @dabreegster ! Feel free to close this issue if you think that it's a duplicated of #857.

dabreegster commented

How does A/B street map understand that there is some kind of road maintenance there?

Not sure what you mean here -- the light pink road in the screenshot is "private / access only", according to some OSM tags. If you link to the OSM object or view from your second screenshot, I can dig into it.

Have you considered to remove the bridges/tunnels edges from the graph, transforming them into virtual deadends for the blockfinder algorithm?

I've tried something like that, a while ago, just haven't gotten it all working yet. Latest experiment was over in https://github.com/a-b-street/osm2streets/tree/planar_graph_literally, trying to work much more generically to create planar graphs on any type of edge -- regular road segments, also edges of water/park areas.

Finally, do the triangulation always work with simple or weakly simple polygons?

Not sure what you mean. The result is supposed to be a bunch of simple polygons. Most of the time, bridges/tunnels or buggy geometry produced by osm2streets is the cause of non-simple polygons.