naml3i / poly2tri

Automatically exported from code.google.com/p/poly2tri
Other
0 stars 0 forks source link

Polygon with hole #104

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
Using this polygon as input:
82 87
74 88
74 96
84 96
84 91

84 91
82 95
77 94
79 89
(Second list is hole)

This is a valid polygon:

    Polygon rings must close
    Rings that define holes should be inside rings that define exterior boundaries
    Rings must not self-intersect—they may neither touch nor cross one another
    Rings must not touch other rings except at a point

What is the expected output? What do you see instead?

Expect to have 7 triangles.

Got 13 triangles. The output mesh contains the tail and head points of Sweep 
line algorithm.

What version of the product are you using? On what operating system?

Last version of poly2tri (rev b85d2568420a )

This input polygon is not supported by poly2tri.js

The fix is relatively simple. Just ignore triangles that contains the point 
DTSweepContext._tail or DTSweepContext._head .

Original issue reported on code.google.com by nico.de...@gmail.com on 20 Apr 2015 at 9:17

GoogleCodeExporter commented 9 years ago
Note, this is a bug on java version of Poly2Tri. This version does not throw 
errors.

Original comment by nico.de...@gmail.com on 20 Apr 2015 at 9:21

GoogleCodeExporter commented 9 years ago
duplicate sorry. There was an error in the first publishing.

Original comment by nico.de...@gmail.com on 20 Apr 2015 at 11:01

GoogleCodeExporter commented 9 years ago
The thing is that this isn't a strictly simple polygon since both outer ring 
and the hole shares a vertex. So this is a weakly simple polygon.

As long as this shared vertex is a single object the triangulator should have 
no problems triangulating. If your polygon contain multiple shared vertexes 
such that all the internal triangles can't form a single edge connected graph 
the cleanup of external triangles will fail.

So poly2tri assumes that vertexes shared by hole and outer ring isn't shared, 
but can handle it if you make sure they are the same object. Poly2tri's simple 
way of cleaning away outside triangles also assumes that all inner triangles 
are connected by atleast one edge so that they form a single graph.

Original comment by thahlen@gmail.com on 20 Apr 2015 at 12:30

GoogleCodeExporter commented 9 years ago
Do you mean that equality check in done with == instead of Object.equals ?

Original comment by nico.de...@gmail.com on 20 Apr 2015 at 12:39

GoogleCodeExporter commented 9 years ago
yes

Original comment by thahlen@gmail.com on 20 Apr 2015 at 12:41

GoogleCodeExporter commented 9 years ago
Can I replace == by .equals or there is a reason ?

Original comment by nico.de...@gmail.com on 20 Apr 2015 at 12:46

GoogleCodeExporter commented 9 years ago
Since the points will contain data to build a connected graph during the 
triangulation. Any input case where two different objects can have the exact 
same coordinate the result of the triangulation is somewhat undefined. poly2tri 
was written to assume that polygon is strictly simple and that there aren't two 
objects with exactly same coordinate supplied in the input.

Original comment by thahlen@gmail.com on 20 Apr 2015 at 12:48

GoogleCodeExporter commented 9 years ago
If you aren't sure all input polygons is strictly simple the solution would be 
to hash the points of the outer ring. Then check if the hole points .equals any 
of the outer points and replace duplicate points them with the already existing 
object.

Original comment by thahlen@gmail.com on 20 Apr 2015 at 12:54

GoogleCodeExporter commented 9 years ago
Ok. Then this could be a preprocessing step. Its true that == test is way more 
faster than Object.equals.

I will change the code to check for duplicates into the method 
Triangulatable.prepareTriangulation . Does its seems to be clean for you ?

Thanks,

Original comment by nico.de...@gmail.com on 20 Apr 2015 at 1:01

GoogleCodeExporter commented 9 years ago
I think I would do these test in the "external code" before adding the holes to 
the poly2tri lib instead of altering the code in poly2tri.

It is a redundant test in every case when you know your polygons are strictly 
simple, thats why I think this test should be done before adding the input to 
the Polygon class.

But in this case you are changing your fork of the poly2tri lib, just for your 
own usage with orbisgis. So where you add this test is up to you. 

My best suggestion in this case would probably be to use this hash in Polygon 
class and do the test every time you add a hole/steiner point. 

Original comment by thahlen@gmail.com on 20 Apr 2015 at 1:47