All functionality is supported for the polygon_with_holes concept. I consider it to be the normal case.
Thanks, that's a relief!
I use my own containers and I missed that I had to declare polygon_traits as
well as polygon_with_holes_traits for my PolygonsWithHoles class. Now things
are working like a charm.
I'm very happing being able to map Qt's QPolygon to Boost.Polygon since this
gives me full rendering capabilities.
I do have a couple of issues and I thought I'd let you know. I'm not sure if
they are outside the scope of the library, so I'll let you be the judge of
that.
1.
Is there an easy(and computationally cheaper) way to check if two simple
polygons intersect?
other than: !boost::polygon::empty(a & b). If not, is such functionality
planned?
2.
The simplify() algorithm seems to be a bit greedy. I have a hard time
thinking up a small example, but I can see it clearly on some larger
GIS-datasets. The algorithm starts chipping away at some corner, removing
unneeded vertices, but in some cases it doesn't stop until the whole polygon
is gone. It seems to me it should work a bit more like Douglas-Peucker:
Everytime a point P is removed, creating a line between A and B, all
previously removed points between A and B should be checked against the
line, and if any of the points end up to far from the line removal of P is
rejected
The way it works now, the accumulated error can be great.
3.
Are there potentially more ways the user can help the library? Right now the
user can override polygon_traits<>::winding(), which is otherwise O(N).
Couldn't the same be done for area, bounding box and concavity. The bounding
box is of course useful for speeding up all boolean operators and knowing
concavity speeds up hit tests ( contains(point_type) ) This could be
calculated in one sweep. No boiler plate code needed if there would be
polygon_default_traits returning winding_unknown, concavity_unknown, etc.
Otherwise, like I said before, it works like a charm.
Sincerely
Björn
2011/9/2 Simonson, Lucanus J
Bjorn,
All functionality is supported for the polygon_with_holes concept. I consider it to be the normal case. All you need to do is create a list or vector of polygon_with_holes_data<int> and use that instead of polygon_data<int> when you get the result out of polygon_set p.
Regards, Luke ________________________________
From: boost-users-bounces@lists.boost.org [mailto: boost-users-bounces@lists.boost.org] On Behalf Of Björn Piltz Sent: Friday, September 02, 2011 1:39 AM To: boost-users@lists.boost.org Subject: [Boost-users] [Boost.Polygon] support for polygons with holes
I'm playing around with Boost.Polygon and I'm wondering what functionality is supported for the polygon_with_holes concept. Specifically the boolean operators.
For example, can I create a polygon_set with polygon_with_holes. I would like to punch a hole in a polygon and get a polygon with a hole as supposed to a key holed contour. Similarily, when combining the following rectangles:
p += rectangle_data<int>(0, 0, 100, 10); p += rectangle_data<int>(90, 0, 100, 100); p += rectangle_data<int>(0, 90, 100, 100); p += rectangle_data<int>(0, 0, 10, 100);
I would like to end up with +-----+ | | | +-+ | | | | | | +-+ | | | +-----+ as opposed to +-----+ | | | +-+ | | | | | | +-+ | | | | +---+-+ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users