I have come across a problem regarding the precision with boost::geometry::intersection.
In the code below I have two clockwise polygons (named 'green' and 'blue') with 'double' points and a precision of 17 decimals.
There are two slightly rotated rectangular polygons. A larger polygon(blue) consisting of 6 points, and another polygon(green) overlapping half of the blue-polygon with 4 (mutual) points.
The intersection of the 'green' with the 'blue' polygon fails to return a result but boost::geometry::intersects indicates there is an intersection.
The reverse intersection 'blue' with 'green' returns the correct result.
If the 17th precision decimal is removed (using 16 decimals), both intersections behave as expected.
Is this a bug, or is there a rule-of-thumb on how to handle these precision problems?
> If the 17th precision decimal is removed (using 16 decimals), both
> intersections behave as expected.
> Is this a bug, or is there a rule-of-thumb on how to handle these precision
This has been solved in the meantime a few weeks ago. So Boost 1.49
gives still this error, but the Boost Trunk handles it correctly. I
could reproduce it using your program.
So hope you are able to upgrade to the Trunk (it's also possible to copy
only Boost.Geometry from the trunk, plus (a part of) Boost.Math).
The general rule is that ttmath handles these cases correctly. I've
never found problems with them. The next rule is that if there is an
issue using a double precision type, it is usually solvable too, so in
that case reports are welcome.