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?
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).
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