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)
• add an alternative using buffer
• add an alternative using correct as submitted in polygon/ring self-intersection correct #868

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%

using buffer
The expectations are a for some cases adapted, because the version using buffer always removes any interior ring.
*** No errors detected

using correct
The expectations are as in the original cases.
*** No errors detected

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

The structure (incl. alignment) of the original file is kept.
What is changed is:

template<
	typename point_t = boost::geometry::model::d2::point_xy<double>, 
	typename ring_t = boost::geometry::model::ring<point_t>
	>

-> (in this case, and also everywhere below)

template <typename Ring, typename PseudoVertices>

sometimes using point_type_t, sometimes another small change. Such that it can be used for any type.

And some minor related changes.

[barendgehrels]

I believe this while can lead to infinite loops. I had it once when changing a thingy.
But in the current unit test, it is always fine.

[barendgehrels]

it is renamed because boost::geometry has already a function called correct

[barendgehrels]

This function is not unit tested, in this PR (it can and gives other results obviously)

[barendgehrels]

This is an overload, and I kept it.
If we productize it we should use the normal dispatch mechanism.

[barendgehrels]

I will add some pictures later this weekend.