Ignore roads outside of working area

[XioNoX]

I think this is a regressions as I don't think it happened before.

For example if I define my neighborhood with those boundaries :

LTN will show lots of "outbound facing" cells on the periphery :

I guess the black dashed line has something to do with it ?

[dabreegster]

The algorithm that detects what roads are inside or outside the polygon you draw is sensitive to floating point imprecision and other things, so we slightly buffer the polygon shape. It's been working this way since early this year, so it'd be strange if this is a new regression you've noticed. Could you send the .geojson export please, so I can check in detail how the polygon shape was made?

[XioNoX]

Thanks!

Brest Saint-Martin-2025-10-01.geo.json

To be renamed .geojson. I marked those stray roads as "primary" to workaround the issue.

For comparaison another neighborhood I'm working on doesn't have this issue (see the roads at the bottom of the working area for example):

Brest - Kerigonan-2025-10-01.geo.json

[dabreegster]

Thanks for the reference files! This issue is a tricky one. There's a clear bug:

1. Draw a boundary using the snapping tool
2. It gets buffered a fair bit, picking up some stray roads sometimes
3. If you adjust boundary, you'll see the original unbuffered thing you drew. If you confirm it again (through the adjust flow), the result is only buffered by the minimal 1m and excludes stray roads.

There's a handful of places we do the buffering, depending on using the auto-generated boundaries or snapping or when merging boundaries. I will work through them carefully and figure out what's happening.

[dabreegster]

Just reviewing how the code works today... What're all the places that do buffering?

• When we auto-split boundaries between severances, we initially just return those polygons, no buffering. We do strip out extremely small "sliver" areas, which tend to happen between dual carriageways.
• As you pick those boundaries, we have two cases. When there's exactly one area, no buffering. But any more and we call generateMergedBoundary, which buffers everything by 15m and then unions them, to deal with those sliver areas.
• If you draw the boundary manually, the input is exactly what you draw. The snapping sticks exactly to the road center-lines.
• Then in neighbourhood.rs, we buffer the boundary input (which in the one case above, will already be buffered by 15m) by 1m before doing the is_road_mostly_inside check.
• Finally, just to display the glow effect in the UI, we buffer by 10m.
• (For stats19 counting, we buffer by an extra 10m. Irrelevant to this bug.)

This code doesn't explain the sequence above though, so let me sanity check what's happening... Oh. The 10m used for the glow/mask is actually the thing that gets saved! That feels unintentional, and like one bug for sure.

In your Saint Martin example above, the extra buffer is explained because you picked two polygons to merge, and the 15m gets added there. If I remove that 15m buffering, this example then works fine -- no stray roads outside. The 15m buffer does have a purpose, though. What could we do?

• Get rid of the 15m buffer, fixing this case, but then breaking dual carriageway cases.
• Maybe we try to union the polygons first, and if it fails (there's a gap between them), then we buffer. But then some places will get unlucky and pick up extra stray roads.
• Maybe we could stop filtering out really small areas. It could be a UI problem -- it's hard to spot and click those small areas. Maybe it could work like this -- if you click a second area, we union and wind up with two disjoint polygons, we do the buffering and look for unselected areas that overlap fully / mostly (at least 50% by area or something) and automatically add those in too.
• Could we revisit roads_mostly_in_polygon and look for those with one endpoint firmly inside the polygon and one outside? But that would break some other use cases, where I've told people to manually adjust an automatic boundary and use the freehand drawing to include something outside, because they want to add a turn restriction.

That 3rd idea is feeling like the best...

[dabreegster]

And reviewing very well-written notes from old PRs:

• Another possible cause is Simplify generated waypoints from "picked" neighbourhoods. #318 -- for auto-generated boundaries, if you later adjust the boundary, we simplify in waypoints_for_ring. Not relevant here / I don't think this is causing problems.
• Tiny "sliver" neighbourhoods preventing "merging" generated boundaries #208 discusses that third idea -- I think indeed we've now found an example where it's necessary / useful.

Do unary union of the original inputs as we do now
If we "fail" (more than one polygon in the result), then find the shortest line connecting a point on polygon1's exterior and a point on polygon2's exterior.
See what other polygons that line intersects, and try including them in the union too
Maybe have limits on the length of that line, or try to preclassify "slivers" and only include those?