Boost C++ Libraries: Ticket #13215: Polygon union give a different result depending of the order https://svn.boost.org/trac10/ticket/13215 <p> I found a precision issue with union between polygons and the result vary depending of the order. </p> <p> We add consecutive polygons to a multi-polygon that contains the previous result. The union of polygons (that have only one outer contour) in the following order give an empty union: </p> <pre class="wiki">Polygon[(-5.180416107177734375,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,4.818223476409912109375),(-2.6576340198516845703125,7.19262790679931640625),(-7.35814762115478515625,7.19262790679931640625),(-7.35814762115478515625,4.818223476409912109375),(-7.35814762115478515625,0.46142292022705078125)] Polygon[(-7.35814762115478515625,-1.8333890438079833984375),(-7.35814762115478515625,-5.162303924560546875),(-3.343097686767578125,-5.162303924560546875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343098163604736328125,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-2.6576340198516845703125,4.79442691802978515625),(-5.180416107177734375,4.79442691802978515625),(-7.35814762115478515625,4.79442691802978515625),(-7.35814762115478515625,0.46142292022705078125)] Polygon[(4.4465618133544921875,-5.162303924560546875),(4.4465618133544921875,-1.195319652557373046875),(3.5822856426239013671875,-1.195319652557373046875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343097686767578125,-5.162303924560546875)] Polygon[(3.5822856426239013671875,-1.195319652557373046875),(3.5822856426239013671875,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-3.343098163604736328125,0.4614227116107940673828125),(-3.3430979251861572265625,-1.19531953334808349609375)] Polygon[(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875)] Polygon[(-0.0815036296844482421875,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-0.0815036296844482421875,-0.438062191009521484375)] Polygon[(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875),(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-0.0815036296844482421875,-0.438062191009521484375),(-0.0815036296844482421875,0.46142292022705078125)] </pre><p> Same polygons in a different order give the expected result: </p> <pre class="wiki">Polygon[(4.4465618133544921875,-5.162303924560546875),(4.4465618133544921875,-1.195319652557373046875),(3.5822856426239013671875,-1.195319652557373046875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343097686767578125,-5.162303924560546875)] Polygon[(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875),(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-0.0815036296844482421875,-0.438062191009521484375),(-0.0815036296844482421875,0.46142292022705078125)] Polygon[(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875)] Polygon[(3.5822856426239013671875,-1.195319652557373046875),(3.5822856426239013671875,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-3.343098163604736328125,0.4614227116107940673828125),(-3.3430979251861572265625,-1.19531953334808349609375)] Polygon[(-0.0815036296844482421875,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-0.0815036296844482421875,-0.438062191009521484375)] Polygon[(-7.35814762115478515625,-1.8333890438079833984375),(-7.35814762115478515625,-5.162303924560546875),(-3.343097686767578125,-5.162303924560546875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343098163604736328125,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-2.6576340198516845703125,4.79442691802978515625),(-5.180416107177734375,4.79442691802978515625),(-7.35814762115478515625,4.79442691802978515625),(-7.35814762115478515625,0.46142292022705078125)] Polygon[(-5.180416107177734375,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,4.818223476409912109375),(-2.6576340198516845703125,7.19262790679931640625),(-7.35814762115478515625,7.19262790679931640625),(-7.35814762115478515625,4.818223476409912109375),(-7.35814762115478515625,0.46142292022705078125)] </pre><p> The result: </p> <pre class="wiki">Polygon[(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875)] </pre><p> Notes: </p> <ol><li>We use float </li><li>This issue happens with mingw32, when tested with Visual 2015 (32bits compilation too) everything is good. Both compiler are used with default options for float precision strategy. </li><li>Prints are made with "%.64g" format option of printf to avoid financial round. </li><li>Those polygons are counter clockwise and open, but I also test them reversed and close, it gives the same result. </li></ol> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13215 Trac 1.4.3 flamaros.xavier@… Mon, 25 Sep 2017 15:57:02 GMT severity changed https://svn.boost.org/trac10/ticket/13215#comment:1 https://svn.boost.org/trac10/ticket/13215#comment:1 <ul> <li><strong>severity</strong> <span class="trac-field-old">Showstopper</span> → <span class="trac-field-new">Not Applicable</span> </li> </ul> <p> Sorry this is a bad report the error is in our side, the issue comes from holes that have a polygon that don't respect the polygon rules. We have some holes that intersect themselves, we will find a way to avoid that. </p> <p> Please accept my apologies. </p> Ticket