Blocks are badly extracted

[TFCx]

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.

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]

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]

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).

• 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]

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.

[XioNoX]

Hopefully not "piling on" with my comment :)
I'm having similar issues in Brest, France, so I'd be happy to help discuss/troubleshot it. See the screenshot below for some more examples.

2 and 3 are most likely bridge related, 1 is odd block selection I can't figure out why.

[dabreegster]

Hi both! Thanks for the patience here. I'm working on a big new version of the LTN tool, and I think the problem with both of these areas is fixed, but I want to be sure. If you go to https://dabreegster.github.io/ltn/, choose your area from the example dropdown, and add a new boundary, you can stretch a polygon over the area(s) you want to analyze. The tool no longer tries to automatically divide everything. If you hit a problem with this, let me know. And if it works decently and your example involves some tricky situation with a bridge, I'd love to use it as a test case. So if you "Save / load project", "Save to GJ", and send the file, I'll set up tests to avoid breaking the area in the future. Thanks!

[TFCx]

I just quickly tested: it seems to be better at handling bridges/tunnels. From what I understand, you now use the reconstructed plannar graph to edit neighbours boundaries (and NOT to handle the routing network)?

I'll dig deeper this week. :)

Thanks for all the hard work. I'm still using A/B street to analyze my city and try some proposals. :) Do you have a blog note about your current and future work? I was wondering last weekend if you were still working on the LTN app. I have discovered a few bugs/crash on the old app I could reproduce if you want (sadly, my Rust left is probably too low to correct them myself).

[dabreegster]

Thanks for testing!

From what I understand, you now use the reconstructed plannar graph to edit neighbours boundaries (and NOT to handle the routing network)?

Exactly. There's no sane way to handle bridges/tunnels otherwise. In the old version, I made too-strong assumptions that the entire perimeter of a neighbourhood is all routable. Some assumptions about forcing the perimeter to be a "main road" were relaxed in #1071. But revisiting things, the only things really needed to calculate shortcuts and cells are interior roads and entrance/exit intersections. Those can both be calculated just by looking at the boundary as a polygon, not using too much of the routing/network properties. It's imperfect in the new version -- sometimes a piece of perimeter road gets marked as interior and has shortcuts shown on it -- but I'm pretty sure those problems can be fixed.

Do you have a blog note about your current and future work?

Not really, the closest thing is https://dabreegster.github.io/prose/dec2023/pt8_tech.html. I've really been meaning to start blogging more frequently, and at least write an updated status for things I'm working on. Will keep you posted if I finish that.

I have discovered a few bugs/crash on the old app I could reproduce if you want

Please do report if it's not too much trouble. The "old" LTN app is still the real usable one, so I'll do my best to maintain it, unless it's things like these boundary problems that're too hard to make work with the old approach. When the newer version has caught up, I'll communicate some kind of migration plan.

[TFCx]

Ok, I've toying with the new version for the last hour. It is really impressive :). I think you have the solution. Thank you very much. I would be impossible to work on some parts of Montpellier without that.

Note that there's still the slight issue with the triangulation if the polygon self-intersect but otherwise, it seems to work on the other case I've tried (even weakly simple polygons work !).

Of course this new version of LTN lacks several major features ("one-ways" is probably the most important for me right now) but now, I can't wait for that version to be released :) Also, the UI is a bit sleeker as well, it's kinda pleasant <3

(Just FYI, there's another tool, "Coplano" to create LTN that I discovered on the main french bike-activist board and that was recently demoed . It's developped by @alxbck at https://github.com/alxbck/street-plan and it uses cocarto tables as its input (cocarto is some kind of excel-like sheet tool specifically aimed to create geographic data collaborativly)).
See a (french) presentation here : https://youtu.be/A5OAFJDGRq8?t=3815

[dabreegster]

@TFCx, some updates. First, I added in one-way support again (it was surprisingly easy the second time around... wish I could say the same for turn restrictions). Second, I started a-b-street/ltn#16 as a dev blog. If there are other big gaps in the new version stopping you from using it, let me know!

And Coplano looks super cool, thanks for sharing!