Open AndrewLipscomb opened 4 months ago
~I've added BOOST_GEOMETRY_NO_ROBUSTNESS
as a define for the system and its gone good now.~
~Far as I can see - thats the new recommended way to run the lib?~
Correction - this did not solve the issue. I was accidentally using an old version when switching Boost versions in CMake.
1.85 and BOOST_GEOMETRY_NO_ROBUSTNESS
don't change the result here.
‘ BOOST_GEOMETRY_NO_ROBUSTNESS’ is deprecated and should not be used.
1.85 has improvemente so thanks for trying that version.
I will look soon.
Sorry for the delay.
Not fixed by my concept fix for #1295 and others. But it's another problem.
Added:
for (const auto& sub : buffered_b)
{
std::cout << " -> " << bg::num_points(sub) << " " << bg::area(sub) << std::endl;
}
Results:
104
1
4
765.094
764.882
-> 139 764.882
-> 4 9.82254e-07
-> 4 9.96362e-07
-> 4 1.01431e-06
So indeed there are three very small polygons, which are not removed because they are valid and having the minimum number of points.
As a workaround you could easily remove them. But it's indeed still classified as a bug and should be looked at.
The following program takes its embedded WKT string, buffers it out by 9m, then back in my 9m.
The geometry itself isn't particularly odd, its a circle-ish blob.
Buffering the geometry out then in in previous versions of Boost geometry (circa 1.71) produced a single polygon.
1.80+ both now produce a small unexpected "stub" - see the picture. This one has 3 of these. This should be a fairly simple operation - can't see any clear reason why it would fail. I tested this with a few versions - 1.79 was the first that didn't do it.
For compiler info and invocation (via CMake)