Hi Barend,
All my polygons are correct, calling bg::correct didn't solve.
But defining BOOST_GEOMETRY_NO_ROBUSTNESS solved both cases...
I'm working with double precision in a small value range (generally 0.0 - 100.0). Is there a recommandation for value ranges ?
Thanks
Regards
Matthieu

On Thu, Mar 7, 2019 at 10:17 PM Barend Gehrels via Geometry <geometry@lists.boost.org> wrote:
Hi Matthieu,

Nice use case! Thanks for your message, I give some suggestions inline.

Op 7-3-2019 om 11:44 schreef Matthieu Beghin via Geometry:
Hi there,

I'm trying to solve my geometry problems with boost::geometry. I really enjoy the API but I'm facing a few issues. Maybe the solutions are simple, but I can't find my way. My context is: users are drawing shapes that are combined using union / intersection / difference, I use "buffer" to have a feathering effect around the shapes and in the end I triangulate the result and render with OpenGL.

Situation 1: if I do a difference between two (valid) geometries that share a common segment, the result is invalid (bg::is_valid return false, it find some "turns"):
Example:
```        namespace bg = boost::geometry;
typedef bg::model::d2::point_xy<double> point_xy;
typedef bg::model::polygon<point_xy> polygon_t;
typedef bg::model::multi_polygon<polygon_t> multiPolygon_t;

multiPolygon_t poly1; bg::read_wkt("MULTIPOLYGON(((-1.00000010731 -0.713619134602,-1.00000012822 -0.493922219801,-0.598172925227 0.100631982002,-1.00000012886 -0.0624283708015,-1.00000011994 0.0862738908136,-0.440262107798 0.31341400405,-0.360828341246 0.292948255722,-0.357275641893 0.210997365241,-0.970143533681 -0.695818118925,-1.00000010731 -0.713619134602)))",poly1);```
`        multiPolygon_t poly2; bg::read_wkt("MULTIPOLYGON(((-0.999999965066 -0.493921978401,-0.909999987372 -0.360755621066,-0.909999996424 -0.91000000872,0.91000000872 -0.909999996424,0.909999996424 0.91000000872,-0.909999996424 0.91000000872,-0.909999911756 -0.0259065349961,-0.999999867625 -0.0624282647935,-1 1,1 1,1 -1,-1 -1,-0.999999965066 -0.493921978401)))",poly2);`
`        multiPolygon_t diff;`
`        bg::difference(poly1, poly2, diff);`

Are you sure the input is closed and has the right (clockwise) orientation? If not, please call bg::correct(poly1) and bg::correct(poly2) before, such that you are sure they are right.

Indeed, if the input geometries are valid,  then the result should be valid. We currently have some issues with some floating point input, and maybe this is the problem for you.

Can you try to define BOOST_GEOMETRY_NO_ROBUSTNESS and see if that helps? This removes the rescaling (that we do internally). In a future release, this (applying overlays without rescaling) will be the default. I'm currently working on it.

Situation 2: the difference between two valid geometries that have no common edge is invalid. The subtracted geometry has an inner hole but I suppose that should be supported...

`        multiPolygon_t poly1; bg::read_wkt("MULTIPOLYGON(((-2 -2,-2 2,2 2,2 -2,-2 -2)))",poly1);`
`        multiPolygon_t poly2; bg::read_wkt("MULTIPOLYGON(((-0.430323140092 -0.999999912736,-1 -1,-1 1,1 1,1 -1,0.431066411049 -0.999999901684,0.43106695576 -1.00000010168,-0.43032321787 -1.00000011274,-0.430323140092 -0.999999912736),(0.135529235005 0.316180944443,-0.949848473072 -0.124261498451,-0.47733861208 -0.590634822845,0.135529235005 0.316180944443)))",poly2);`
`        multiPolygon_t diff;`
`        bg::difference(poly1, poly2, diff);`

`On this picture poly1 is in green, poly2 is in red (the red triangle is poly2 inner hole).`

Indeed holes are supported. This is probably not a Floating Point issue, so I guess this might be the orientation, could you try also here to correct the input before calling difference?

If this all doesn't help, I will try to reproduce the problem.

Regards, Barend

_______________________________________________
Geometry mailing list
Geometry@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/geometry