So only in float we have the real spike. The output is indeed not checked on these cases. They should not be generated but in float they apparently are, because of the lower resolution.

So this could really be considered as an issue ? Do you think a solution could correct this behaviour or must we deal with it ? I'm not asking for a fix, I currently use Boost.Polygon to achieve what I want - just wanted to test it with Boost.Geometry since it can work with float (I currently convert my float space to int space to work with Boost.Polygon). As I found this corner case I thought it could be usefull to report it.

Sure, your report is very useful.
Yes it is an issue, a spike should not be there. I will think about how it can be avoided efficiently.

Besides that, another solution (which was already planned for the cases of Volker Schöch) is that the intersection can deal with spikes. The union would then still have a spike, but algorithms later on do not throw on that. I have to do more research on this.

 

Did you try the complete program (so including the steps after this union) with double? Is it then also reporting the self-intersection? You probably cannot use float for this case... We can filter out the spike in a post-process, as you suggest, but it is (at least not now) the intention to do this by default.

It requires many changes in my program, it is a currently in a big project (point type is not a template since I knew I wanted floating numbers). I will try to extract the entire algorithm and make a simple test program for it.

OK, thanks.

Regards, Barend