Menu

#189 Issue with polygon Union

*
open
nobody
union (2)
1
2018-12-15
2018-12-15
Anonymous
No

Hi,

We've come across a simple set of inputs for the Union operation which do not seem to give the correct result. Here are the inputs formatted for the C++ clipper_console_demo.exe:

subj.txt:
4, 1
3, 1
3, 0
4, 0

clip.txt:
5, 2
0, 2
0, 1
5, 1

2, 1
1, 1
1, 0
2, 0

Command line:
clipper_console_demo subj.txt clip.txt UNION NONZERO NONZERO 0 100

The two smaller squares (one in subj.txt, one in clip.txt) are both abutting the larger rectangle from clip.txt, so the result should be a single polygon. However the smaller square from clip.txt does not get unioned, as you can see in the svg result (two shapes):

path d=" M 410.00 10.00 L 410.00 110.00 L 510.00 110.00 L 510.00 210.00 L 10.00 210.00 L 10.00 110.00 L 310.00 110.00 L 310.00 10.00 z M 210.00 110.00 L 110.00 110.00 L 110.00 10.00 L 210.00 10.00 z"

If you run the command with the subj.txt and clip.txt swapped, you get a single result shape, which is expected:

path d=" M 210.00 10.00 L 210.00 110.00 L 310.00 110.00 L 310.00 10.00 L 410.00 10.00 L 410.00 110.00 L 510.00 110.00 L 510.00 210.00 L 10.00 210.00 L 10.00 110.00 L 110.00 110.00 L 110.00 10.00 z"

I was able to reproduce this with the C# console demo and the javascript port (http://jsclipper.sourceforge.net/6.2.1.0/main_demo.html), though with those versions I the original subject/clip inputs worked fine, but swapping them resulted in two output shapes.

Not sure if this is a real issue or user error?

In any case, thanks very much for all your work on Clipper!

Best Regards,
Duncan

Discussion

  • Angus Johnson

    Angus Johnson - 2018-12-15

    Hi Duncan. This isn't a bug because there's no guarantee (in the documentation) that common edges in solutions will be joined. This is something I'm addressing in Clipper2 that's progressing but still a way off.

     
  • Anonymous

    Anonymous - 2018-12-15

    Hi Angus,

    Understood, and thanks very much for the quick response.

    I had the thought that if I could detect that the result had abutting polygons, I could try re-running the union on the output shapes, maybe with order swapped. I see in Clipper::JoinCommonEdges() the code:

    if (!JoinPoints(join, outRec1, outRec2)) 
        continue;
    

    I hit that 'continue' when I get two output shapes, and it does not get hit if I change the input order and a single output shape is returned. Do you think it makes sense to report that there was a join failure in some way (maybe just setting a boolean m_couldNotJoinOputShapes=true, or someting)? Or are there cases where you could have abutted output shapes, which cannot be detected?

    Thanks and Best Regards,
    Duncan

     

Anonymous
Anonymous

Add attachments
Cancel





MongoDB Logo MongoDB