Geometry Boost List: [ggl] Within polygon detection including the polygon borders

Subject: [ggl] Within polygon detection including the polygon borders
From: Ivan Marin (ispmarin)
Date: 2009-09-21 11:00:14

Hello all,

<snip>
> Good that the latest version solves this anyway.
>

Yes, I've just confirmed, and it seems that the svn version is working
properly. I will now do more tests. Thank you very much for your help.

>
> >
> > 1) In the testprogram: the polygon is not defined correctly: {100.0,
> 100.0},
> > {200.0, 200.0}, {100.0, 200.0}, {200.0, 100.0}, {100.0, 100.0}
> >
> > the polygon starts at lowerleft, goes to upper-right, then to upper-left,
> > then to lower-right, then closes. The code before
> >     ggl::point_2d c3 = make<point_2d>(100,100);
> >       ggl::point_2d c4 = make<point_2d>(100,200);
> >       ggl::point_2d c5 = make<point_2d>(200,200);
> >       ggl::point_2d c6 = make<point_2d>(200,100);
> >       ggl::point_2d c7 = make<point_2d>(100,100);
> > was correct and as intended, but that code is not used (anymore)
>

So, what is the correct way to define the points? Anti-clockwise, starting
in the lower left point?

> >
> > Therefore the centroid point also gives a strange value (0, 1e+006).
>

Yes, this happens when the points are defined in the other sense. Is there a
way to test for ill defined points or point insertion order?

> >
> > 2) In the library (preview 4): the results are still wrong indeed, using
> > preview 4. Using the head (hosted at Geodan SVN) it is OK. The code in
> > preview4 didn't handle points on segments correctly, this was solved in
> the
> > meantime. So I updated preview 4, hosted at Boost SVN, with the new code
> and
> > it is OK now.
>

Yes, I've just downloaded the svn version, and it's working.

>  >
> > Ivan, note that you can also have SVN access to the Geodan SVN, you're
> > working then with the newest versions, up for Boost preview or review
> next
> > month, if this is feasable.
>

I will follow now the svn version.

Thank you very much.

Regards,
Ivan

>  >
> > Regards, Barend
> >
> >
> >
> >
> >
> >
> > Ivan Marin wrote:
> >
> > Hello Mr. Barends,
> >
> > 2009/9/18 Barend Gehrels <Barend.Gehrels_at_[hidden]>
> >>
> >> Hi Ivan,
> >>
> >> Sorry for my very late reaction. I was on holiday from Sep 3 on.
> >>
> >>
> >>>
> >>> I successfully compiled the examples
> >>
> >> Does this mean I can ignore your other question of Sep 3?
> >
> > I was able to compile the examples, but what I did was kind of a hack:
> I've
> > just copied the directory geometry to /usr/include. Putting it on the
> local
> > directory or inside the boost directory did not work, and I was puzzled
> by
> > that. But it is working.
> >
> >>
> >>> and now I'm trying to use the ggl. I need to check if a point is inside
> a
> >>> polygon, and I want to consider de borders as part of the polygon. Is
> this
> >>> possible in ggl? All the tests that I've made showed me that this is
> not
> >>> possible.
> >>
> >> That is right, currently it is not possible. We will have another
> function
> >> which can be used for this question. It will either be an option of
> >> "within", or it you could use the "distance" function on point-polygon,
> >> which is zero or if the polygon is on the border or inside. Actually the
> >> last one can also be discussed, if the point is inside the polygon, it
> could
> >> be less than zero or also as an option.
> >
> > Ok, I see. Now I've developed my theory that if I can say if the point is
> > just inside the polygon will suffice. The problem now that I was
> discussing
> > with Bruno is that there is a case where the routine within is not
> working
> > properly: if I define a polygon with vertices 100 100, 200 100, 200 200,
> 100
> > 200, and search for all the points inside the polygon, the routine
> outputs
> > points that are not inside the polygon as inside. Bruno was able to
> > reproduce this bug. I attached the code that I used to produce this
> problem.
> > Is there a proper place to submit a bug report, or is any more data
> needed?
> > I'm willing to help, and if possible, even debug.
> >
> >>
> >> But both are currently not implemented.
> >
> >
> > Thank you very much!
> >
> > Best regards,
> >
> > Ivan Marin
> > Laborat?rio de Hidr?ulica Computacional - Computational Hydraulics Lab -
> LHC
> > Depto de Hidr?ulica e Saneamento - Sanitation and Hydraulics Dept.
> > Escola de Engenharia de S?o Carlos - Universidade de S?o Paulo - EESC -
> USP
> >
> >>
> >> Best regards,
> >> Barend Gehrels
> >> Geodan, Amsterdam
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> ggl mailing list
> >> ggl_at_[hidden]
> >> http://lists.osgeo.org/mailman/listinfo/ggl
> >
> > ________________________________
> > _______________________________________________
> > ggl mailing list
> > ggl_at_[hidden]
> > http://lists.osgeo.org/mailman/listinfo/ggl
> >
> > --
> > -------------------------------------
> > Barend Gehrels
> > -------------------------------------
> > http://www.erplex.com
> > http://geometrylibrary.geodan.nl
> > http://www.geodan.nl
> > -------------------------------------
> > Geodan Holding b.v.
> > President Kennedylaan 1
> > 1079 MB Amsterdam
> > The Netherlands
> > -------------------------------------
> > Tel: [phone]
> > Mob: [phone]
> > Fax: [phone]
> > -------------------------------------
> > E-mail: barend.gehrels_at_[hidden]
> > Kvk-nummer: 33 207089
> > Disclaimer: www.geodan.nl/disclaimer
> > -------------------------------------
> >
> > _______________________________________________
> > ggl mailing list
> > ggl_at_[hidden]
> > http://lists.osgeo.org/mailman/listinfo/ggl
> >
> >
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090921/98062b09/attachment-0001.html