The policy of this list is: don't top-post. I reordered your mail to read from top to bottom, my answers in between.

Sorry for the inconvenient, I knew it but gmail hid your answer in my reply form (have to click a button to show it)...

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.

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.

Regards, Olivier.