boost::polygon_90_data can not handle polygons with 0 area value?

135 Views Asked by At

My polygon has integer coordinates and may be like a line, I find boost::polygon_90_data can handle some of them, but this one can not be:

namespace gtl = boost::polygon;
typedef gtl::polygon_90_data<int> Polygon;
typedef gtl::polygon_traits<Polygon>::point_type Point;
Polygon poly;

Point pts5[] = { Point(100, 200), Point(200, 200), Point(200, 400), Point(200, 200), Point(100, 200) };
gtl::set_points(poly, pts5, pts5 + 5);
contain = gtl::contains(poly, Point(197, 202)); // expect false
contain = gtl::contains(poly, Point(200, 302)); // expect true
contain = gtl::contains(poly, Point(200, 400)); // expect true
contain = gtl::contains(poly, Point(150, 200)); // expect true

In 2,3 conditions, gtl::contains return false, even through Point(200, 400) is a coordinate specified by myself. So why? Is there some restrict on using gtl::polygon_90_data?

1

There are 1 best solutions below

1
On BEST ANSWER

I think any planar geometry with a zero area is by definition self-intersecting.

Geometry algorithms often deal badly with those and the preconditions are likely documented. At this point I can't find such documentation with Boost Polygon/GTL.

From what I gather reading the source code, some overloads/variations of contains accept a boolean argument consider_touch that might help you out. Beware of unspecified behaviour though. (E.g. the polygon/polygon implementation counts intersections, and counting intersections with overlapping edges is going to be... questionable).

TL;DR:

I'd use a segment/line for non-planar geometries, so that you don't startle any of the (undocumented?) geometry invariants or algorithm preconditions