Fix/buffer use cluster for within piece

[barendgehrels]

This is a follow-up of #1369
I wrote it in February, after first PR - and just rebased it and retested it.
It is much smaller.

What can happen that one point is considered as within another piece (that's good) but another clustered piece is not considered as within, or it is considered as within the first piece. This is all caused by floating point behaviour.

It happens with both side strategies (robust and by_triangle)

This fix is simple, it considers clusters and the pieces involved, and does not even need to perform a within-check in those cases.

Behaviour, before (on current develop, this is the same as reported in #1369 but there it was on that branch):

geometries: 603809 errors: 506 type: d time: 67.478
geometries: 610519 errors: 417 type: d time: 63.547 (robust side)

Behaviour, after the fix

geometries: 608834 errors: 430 type: d time: 68.572
geometries: 615232 errors: 333 type: d time: 64.119 (robust side)

So roughly 25% improvement. A few of these are added to the unit test suite.

In terms of pictures, it's a big difference often - it cannot make the output if some turns are classified as "within". The orange/red dotted line is the resulting buffer.

Before (the turn labelled as 7 is classified wrongly)

After:

[barendgehrels]

This is the fix

[barendgehrels]

This does not make any difference - but it should have been true

[barendgehrels]

These new 5 all fail in develop

[barendgehrels]

What will be the follow-up...

The statistics indicate that the side_robust is another big improvement and we can turn it on, at least for the buffer algorithm. That will increase another 25%.

I just tested the buffer-unit tests and there are only two regressions, w12 and w20. This apart from a lot of improvements which are not yet in the test-suite.

During rewriting graph traversal, some cases were analyzed and postponed because increased the scope too much.

These are unfinished - but marked as BOOST_GEOMETRY_CONCEPT_FIX_ARRIVAL and BOOST_GEOMETRY_CONCEPT_FIX_START_TURNS. They are slightly related.

The BOOST_GEOMETRY_CONCEPT_FIX_ARRIVAL currently fixes both w12 and w20 so this looks good. Therefore we could already use that side strategy (temporary excluding the failing cases) and fix the arrival cases later. Or the other way round, first fix the arrival cases (which will be harder - I already started in February but did not succeed yet) and then enable the strategy.

I think it's more pragmatic to enable first the robust side strategy - for buffer.

[tinko92]

The code looks good to me and catching something through the algorithm logic before predicate calls seems good.

When running the full test suite on my ARM64 machine (Linux magicbook 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:19:58 UTC 2024 aarch64 GNU/Linux), I get 10 new test case failures in algorithms_buffer_linestring_geo that I do not get on develop:

[...]/test_buffer_geo.hpp(83): [...] aimes_67_rr has too many points too close 1 0.25
[...]/test_buffer_geo.hpp(107): [...] aimes_67_rr the area is too small, expected at least 1.0038978240812866 15735.3694290676200406610455466882215
[...]/test_buffer_geo.hpp(83): [...] aimes_67_rf has too many points too close 1 0.25
[...]/test_buffer_geo.hpp(107): [...] aimes_67_rf the area is too small, expected at least 1.0038978240812866 13870.0487909986804213579532542697212
[...]/test_buffer_geo.hpp(107): [...] aimes_67_mf the area is too small, expected at least 1.0038978240812866 13870.0487909986804213579532542697212
[...]/test_buffer_geo.hpp(83): [...] aimes_163_rr has too many points too close 0 nan
[...]/test_buffer_geo.hpp(107): [...] aimes_163_rr the area is too small, expected at least 0 6078.31722878943595932505319884877138
[...]/test_buffer_geo.hpp(107): [...] aimes_181_rr the area is too small, expected at least 198.67884304160947 13456.4538307680239549585864667961117
[...]/test_buffer_geo.hpp(83): [...] aimes_163_rr has too many points too close 0 nan
[...]/test_buffer_geo.hpp(107): [...] aimes_163_rr the area is too small, expected at least 0 6078.31722878943595932505319884877138

*** 10 failures are detected in the test module "Test Program"

If they don't occur for you maybe this is related to long double being float128 on my machine (the numbers in this output look like long doubles) and can be ignored and addressed later (since that also causes other errors on develop already on my machine).

Edit: Changing side strategy does not change these 10 additional test failures for me.

[tinko92]

This produces a comparison of integers of different signedness (long int and size_t) warning in algorithms_buffer_linestring_aimes.test and other tests.

[barendgehrels]

When running the full test suite on my ARM64 machine, I get 10 new test case failures

Thanks for testing! Indeed I don't get this. I've arm64 but not float128.
Darwin Kernel Version 23.6.0: Thu Mar 6 21:58:56 PST 2025; root:xnu-10063.141.1.704.6~1/RELEASE_ARM64_T6020 arm64

if they don't occur for you maybe this is related to long double being float128 on my machine and can be ignored and addressed later

Good you mention this. I tested the buffer algorithms but not yet the geo-ones. I will recheck.

The aimes tests are fragile (some of them) - indeed we might ignore them.

[barendgehrels]

Good you mention this. I tested the buffer algorithms but not yet the geo-ones. I will recheck.

All fine. The only check failing is boost_geometry_index_rtree_exceptions_rst - which also fails for me on develop. It is not related - I would be happy if it could be fixed or skipped

[barendgehrels]

If they don't occur for you maybe this is related to long double being float128 on my machine

The long double is not tested in the default test suite configuration...

#if ! defined(BOOST_GEOMETRY_TEST_ONLY_ONE_TYPE)
    test_linestring<bg::strategy::andoyer, true, bg::model::point<long double, 2, bg::cs::geographic<bg::degree> > >();
#endif