# Geometry :

Subject: [ggl] Within polygon detection including the polygon borders
From: Ivan Marin (ispmarin)
Date: 2009-09-21 16:48:13

Hello again, Barend,

2009/9/21 Barend Gehrels <Barend.Gehrels_at_[hidden]>

> Hi Ivan,
>
>
>
>
> So, what is the correct way to define the points? Anti-clockwise, starting
> in the lower left point?
>
> Note that it was not the *clockwise* *order* which was not correct, but
> the points were ordered wrong (hard to explain).
> Because you're calling "correct", you can enter them in any order. If not,
> you have to enter them in clockwise order.
> Lower-left is not relevant here, you can also start with upperright and in
> polygons with more than 4 points this is actually hard to define. You can
> start anywhere.
>

Is there any documentation about this point order thing? I'm interested, as
this is important for my simulation, and if there is some sort of standard I
would like very much to read it. I will call correct to order the points,
thought.

>
>
>
>
>
>
>> >
>> > 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?
>
> So it probably does not happen if the points are clockwise or
> anti-clockwise, but it happens if points are in orders like 1,3,2,4. It then
> gets a self-intersection and indeed, a function to test that is valid, is
> required for OGC compliance, but is not yet implemented...
>

Is there any prevision for the intersection test routine? Or maybe I can
help with this routine, if possible - this also interests me a lot.

>
>
>
>
>> >
>> > 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.
>
> You mean the Boost.SVN version?
>

No, the Geodan SVN. I was able to put to work together the boost trunk and
Geodan svn, boost 1.40 and Geodan svn, but not boost sandbox and ggl from
Geodan or the sandbox itself. Really don't know why not, it just doesn't
find ggl, no matter the paths for the files in /usr/include.

>
>
>
>> >
>> > 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.
>
> No problem, you're welcome
>
> Regards, Barend
>

If there is any references, or if I can help, please contact me.

Regards,

Ivan

>
>
>
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090921/bc17c895/attachment.html

Geometry list run by mateusz at loskot.net