Fix/issue 1410 repair dissolve

[barendgehrels]

This PR:

• prepares the traverse algorithm such that it supports dissolve better
• fixes compilation in dissolve
• fixes the unit test (and adding geojson)

Test results:
original case

It is mostly as it was before. Note that the versions 1.85 did not run without errors either. Removing duplicate cases,
there are just two errors now.

Running 1 test case...
dissolve.cpp:147: dissolve: ggl_list_denis #clips expected: 2 detected: 1 type: d
dissolve.cpp:150: difference{23.2553} between length_or_area{870.87609377304386} and expected_area{21123.328099999999} exceeds 0.001%

dissolve.cpp:150: difference{0.171709} between length_or_area{30.711676315570951} and expected_area{26.210999999999999} exceeds 0.001%

[tinko92]

The changes look good to me (make all calls consistent with the removal of rescale policies, replace svg mapper with geojson in testing). I noticed no new failures in the main test suite, as expected based on the changes.

Two things I noticed, though:

1. line 13, run dissolve.cpp is still commented out in geometry/extensions/test/algorithms/Jamfile in your branch. If I run that test, I get 63 failures on my only tested configuration linux, aarch64 with gcc (7, 8, 9, 12, 13, star_{a, b, c}, mail_2017_09_24_{e,f}, mail_2017_09_30_a, reallife, gitter_2013_04_b, ggl_list_denis, mail_2018_08_19 all with types f and d). That does confirm that it compiles, though.
2. The compilation issues of dissolve would have been caught by a minimal test. Would we want such a test as part of the CI for extensions which are intended for future inclusion and active usage?

[barendgehrels]

Thanks for your remarks!

Two things I noticed, though:

1. line 13, run dissolve.cpp is still commented out in geometry/extensions/test/algorithms/Jamfile in your branch. If I run that test, I get 63 failures on my only tested configuration linux,

Indeed. The results are different than from before, I still have to work on that.

That does confirm that it compiles, though.

Indeed

2. The compilation issues of dissolve would have been caught by a minimal test. Would we want such a test as part of the CI for extensions which are intended for future inclusion and active usage?

Good question. We don't have them for extensions. They are meant to be

• candidates for the "real" library (though some already for way too long)
• extra functionality which will not make it
• maybe I miss some.

Also they should not be part of master and therefore I always split commits (extensions only / no extension code affected). Integrating it will make it (maybe) more inconvenient.

@vissarion what are your thoughts?

[barendgehrels]

I first wanted to make a follow-up. But because it is not merged (neither approved) anyway, it can be done in this PR

[barendgehrels]

I will add some pictures later this weekend.

[barendgehrels]

Code within this while-loop is all the same as before.
But we don't call itself recursively anymore (for large geometries on some operating systems, this could result in a stack overflow). It is just a while loop now which was a trivial change, and much better. If there are many turns (for example for equal geometries), it can loop for (for example) more than 3000 times which should not cause any problem.

[barendgehrels]

This was a recursive call, not wise in hindsight.
@vissarion We should get this fix in 1.89. It is still allowed. I will make a separate PR for this.
It causes problems in big polygons with lots of turns (for example two equal polygons of 3500 points).

[vissarion]

Sorry for being late reviewing here. I saw that some changes are separated in another PR and merged. @barendgehrels what is the status of this PR?

[barendgehrels]

Sorry for being late reviewing here. I saw that some changes are separated in another PR and merged. @barendgehrels what is the status of this PR?

Hi @vissarion - sorry, I overlooked this comment. It was a kind of research PR. I'm now busy with it again based on the issue opened by Johan Dore #1472

I will open a new PR

[barendgehrels]

The PR is rebased and updated. Experimental similar algorithms (and tests) are left out, based on a robustness test (that I will work out later).

This should unblock Johan Dore in #1472

It should not yet be merged, the diff with the develop branch is substantial, I like to do some additional tests first.