2

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?

genpfault
  • 51,148
  • 11
  • 85
  • 139
kyleqian
  • 311
  • 1
  • 3
  • 14

1 Answers1

2

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

sehe
  • 374,641
  • 47
  • 450
  • 633