On Thu, Nov 6, 2014 at 3:47 PM, Menelaos Karavelas <menelaos.karavelas@gmail.com> wrote:
Yet one more comment.I think what is happening is that the BG code understands your ring as a container of points (a multipoint/vector of points/etc), rather than a multipolygon, in which case it is setup to output just the intersection points.
On 06/11/2014 11:44 μμ, Menelaos Karavelas wrote:
Hi again.
On 06/11/2014 11:34 μμ, Menelaos Karavelas wrote:
Hi Will.
On 06/11/2014 11:26 μμ, Will Lucas wrote:
On Thu, Nov 6, 2014 at 3:07 PM, Menelaos Karavelas <menelaos.karavelas@gmail.com> wrote:
Dear Will,
I tried your polygons and the intersection seems to work.
Please checkout the attached program, and let us know if you get a similar output. The output that I get is:
MULTIPOLYGON(((75 150,250 150,250 75,75 75,75 150)))
Best,
- m.
On 06/11/2014 10:44 μμ, Will Lucas wrote:
Hi all,
I have a question regarding the intersection of ring concepts using Boost.Geometry. I currently have two overlapping rectangles defined by the following WKTs:
POLYGON((75 75,75 175,275 175,275 75,75 75))POLYGON((50 50,50 150,250 150,250 50,50 50))
When I perform the intersection of these rectangles, I get the intersection points:
POLYGON((75 150,250 75))
The intersection points do not allow me to compute the area correctly after the intersection. Is there way to get a fully valid ring/polygon out of intersection, so that the area will be equal to the overlapping region?
Thanks!Will
_______________________________________________ Geometry mailing list Geometry@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/geometry
_______________________________________________
Geometry mailing list
Geometry@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/geometry
Menelaos,
Thanks for the quick response! I have tested your code, and it correctly outputs
MULTIPOLYGON(((75 150,250 150,250 75,75 75,75 150)))
I had to comment out the is_valid calls as I'm running the Ubuntu package (boost 1.54.0), which doesn't contain that helper method.
Sure, this was just a sanity test.
I'm guess the problem may be my re-mapping of the OpenCV data-types. Here is what I currently am working with
Do I need to define a polygon wrapper for the custom Contour type I have?
I think that the problem is that your intersection output type should be a multipolygon rather than a ring/polygon. Please checkout the relevant doc page:
http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/algorithms/intersection.html
Try replacing the intersection output type by a multipolygon, or a vector/deque of polygons and see what the output is.
Please see the updated attached program. I added one more call to bg::intersection specifying a ring as the output (like you do), and I get the result you get. I am now convinced that the problem is what I describe above.
- m.
All the best,
- m.
- m.
_______________________________________________ Geometry mailing list Geometry@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/geometry
_______________________________________________
Geometry mailing list
Geometry@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/geometry
So, it sounds as if I should follow along with this custom polygon example?
This would hopefully allow me to define a custom multi_polygon. As my initial attempt to just create an std::vector<dft::Contour> as a multi_polygon, resulted in a bunch of compiler complaints :D
For my specific problem, I'm not concerned with "holes" that may exist in a polygon (I actually indicate to OpenCV, to only return the exterior contours to me). Is there a way to indicate to BG that only exterior contours are used via the polygon traits?
I suppose worst case I can copy from OpenCV to BG data-structures, but that doesn't seem as elegant :)
Will
_______________________________________________ Geometry mailing list Geometry@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/geometry