0

i'm trying to find intersections in a polygon. specifically i'm interested in collinear intersections, where two segments just lie on top of each other and intersect on all the common part. i think it has something to do with the policy , but not sure how to define the right one. would appreciate any help.

namespace bgi = boost::geometry::index;
  namespace bg = boost::geometry;
  using namespace std;
  typedef bg::model::d2::point_xy<double> point_2d;
  typedef bg::model::polygon<boost::geometry::model::d2::point_xy<double> > Polygon;
  Polygon poly;
  poly.outer().push_back(point_2d(0, 10));
  poly.outer().push_back(point_2d(5, 10));
  poly.outer().push_back(point_2d(5, 5));
  poly.outer().push_back(point_2d(2.5, 15));
  poly.outer().push_back(point_2d(0, 5));
  poly.outer().push_back(point_2d(0, 10));
  poly.outer().push_back(point_2d(0, 20));
  poly.outer().push_back(point_2d(0, 10));



  typedef bg::point_type<Polygon>::type point_type;
  typedef bg::detail::overlay::traversal_turn_info
   <point_type,typename bg::segment_ratio_type<point_type, bg::detail::no_rescale_policy>::type> turn_info;

  bg::detail::self_get_turn_points::no_interrupt_policy noInteruptPolicy;
  bg::detail::no_rescale_policy robust_policy;
  std::vector<turn_info> turns;
  bg::self_turns<bg::detail::overlay::assign_null_policy>(
    poly, robust_policy, turns, noInteruptPolicy);
  • I suppose it would be classy for you to post the answers you received on the mailing list. – sehe May 11 '16 at 22:54
  • So i asked this question on the boost mailing list, and this is the answer i got: My question: I tried on this polygon : Polygon poly { { { 10, 10 }, { 20, 10 }, { 20, 5 }, { 25, 5 }, { 25, 7 }, { 30, 7 }, { 30, 3 }, { 25, 3 }, { 25, 5 }, { 20, 5 }, { 20, 0 }, { 10, 0 }, { 10, 10 } }}; and all i get is that there are two intersection points, and both are "touch". and when i ran on your examples i got 4 collinear. is it a bug? am i doing something wrong? – Sergey Benkovitch May 15 '16 at 10:54
  • the answer i got: No, everything is ok. The turns are oriented, so they reflect how segments interact with each other when the edges of both geometries are traversed clockwise. The only difference between 2-parameter version and self-intersection version is that the turns for the same segments are not generated because they'd all be equal. – Sergey Benkovitch May 15 '16 at 10:57
  • So in your example at 2 points the edges touch and later goes in different ways. For {20, 5} the touch turn is generated with block/intersection operations, for {25, 5} it's also touch turn but the operations are intersection/block. It's because if we wanted to calculate the intersection (a set operation, set product of areas) of these geometries at point {20,5} we should go to {20, 0}, not to the {25,5} which is the next point on the edge and at {25,5} it's the opposite. – Sergey Benkovitch May 15 '16 at 10:58
  • In this case: Polygon poly{ { {0, 0},{0, 10}, {10, 10}, {10, 0}, { 10, 10 },{ 0, 10 },{ 0, 0 } } }; 4 x (equal, collinear/collinear) turns are generated because if they were different geometries and we wanted to calculate intersection or union we could follow any of the edges in both cases. – Sergey Benkovitch May 15 '16 at 10:58
  • In my second example: Polygon poly{ { { 0, 0 },{ 0, 10 },{ 10, 10 },{ 10, 0 },{ 0, 0 },{ 0, 10 },{ 10, 10 },{ 10, 0 },{ 0, 0 } } }; – Sergey Benkovitch May 15 '16 at 10:59
  • 2x (touch, block/block) turns are generated because we shouldn't follow any of these points if we wanted to calculate union (sum of areas) or intersection (common areas). The are collinear-opposite so if Polygons were valid some other turns should be generated besides these, some union/block or intersection/block so we'd follow them and ignore block/block ones. – Sergey Benkovitch May 15 '16 at 10:59
  • Did that answer things? It's not evident to me. If so, please add an answer. – sehe May 17 '16 at 00:17

0 Answers0