Closed GoogleCodeExporter closed 8 years ago
p.s. I'm referring to Java version of Poly2tri library.
Original comment by runit...@gmail.com
on 1 May 2014 at 4:38
Well when adding holes what you actually do is add points and constraints for
the triangulation. This data you should already have before using poly2tri to
triangulate so I don't see why you need poly2tri to return these holes?
Outer hull, holes and steiner points are all just bunched up as a list of
points and constraints when triangulating. What you get in return is the
triangles that are considered to be inside of the polygon.
addHole is just a convenient way of adding points and edges to the
triangulation context. There is really no holes to return after triangulation.
Original comment by thahlen@gmail.com
on 2 May 2014 at 9:59
I know that getHoles() would return the same points that I gave it using
addHole() method, and yes I could just save those points somewhere else in my
program and use Hashtable to match it with any given Polygon object, but why
are you forcing this inconvenience on us??
I need getHoles() for my own calculations. For example, I add holes in one part
of my code and in a different part I need to read the holes and adjust them to
ensure they don't collide with each other.
You already have a getPoints() method, why not add a getHoles() method too?
It's standard practice that every setter would have a getter so that you don't
lose access your own input data.
Original comment by runit...@gmail.com
on 10 May 2014 at 5:24
I'm not really happy with the API interface. I had plans to make a Polygon
manipulation library and have the Polygon class be used by several different
tools not just triangulation.
Since that didn't come to fruition I would rather have seen Polygon class just
as a context for for passing data to the triangulator.
To solve your issue just do
package org.poly2tri.geometry.polygon;
public class MyPolygon implements Polygon
{
public List<Polygon> getHoles()
{
return _holes;
}
}
and use that instead of Polygon
Original comment by thahlen@gmail.com
on 10 May 2014 at 10:58
Your solution is actually what I had already implemented. But still, I think
many of your non-pro users wouldn't recognize that _holes is protected and can
be access this way. Also is add one more class to project that was otherwise
unnecessary.
Furthermore, it's inconsistent with the current API. You have getPoints()
methods but not getHoles(). If you decided to make Polygon just a context for
passing data, are you going to remove getPoints() as well? That'd be even more
inconvenient but at least consistent with not having any getters.
My thoughts is that the majority of the users of your library expect getters
and are surprised that there is a missing getter. A simple shortcoming like
that could deprive you of thousands of potential users because most would
assume that missing basic getters is a sign that library is not complete and/or
reliable. Whereas in reality I think it's a fantastic library.
Original comment by runit...@gmail.com
on 17 May 2014 at 2:18
Original issue reported on code.google.com by
runit...@gmail.com
on 1 May 2014 at 4:36