Re: [Gpsbabel-misc] Polygon Filter

[Ron P. <ro...@pa...>]

[oops, forgot to reply all on this one; resending it to the list for the 
archives.]

At 08:48 PM 3/6/2004, you wrote:
>Although not specifically stated in the documentation I also suspect the
>order of the points creating the polygon is significant. I say this because
>I tried all sorts of permutations changing the order of the coordinates and
>did manage to get a different number of points returned in the result set
>at times.

Yeah, the language in the README is a bit math-heavy ("closed cycle").
The order is significant, and you MUST make sure that the last point is the
same as the first point.  For example, the "square" referenced in the readme:

           # A square (not really) polygon
           41.0000       -85.0000
           41.0000       -86.0000
           42.0000       -86.0000
           42.0000       -85.0000
           41.0000       -85.0000

Note that there are FIVE points specified; each pair of points is an edge
of the polygon, and because the last point is the same as the first point,
the polygon is closed.  If you did this instead:

           41.0000       -85.0000
           42.0000       -86.0000
           41.0000       -86.0000
           42.0000       -85.0000
           41.0000       -85.0000

(same points, but not the same order) you'd get a bowtie-like thing
instead of a "square", and only half the points you'd expect to see
would be inside it.

If you do this:

           41.0000       -85.0000
           41.0000       -86.0000
           42.0000       -86.0000
           42.0000       -85.0000

You might think you have a square, but you'll find that you get a lot
of points that shouldn't be inside it thinking they are, or vice-versa.
The reason is that it uses the odd/even rule to determine insideness,
so if the polygon isn't closed the insideness of a given point is
heavily dependent on the direction of the test ray.  I see from your
message that this isn't the problem, but I mention it for the sake of
others who might be reading the mailing list in search of answers on
similar problems.

>I can provide input file, polygon coordinates, and command syntax, if
>needed. However, I thought I would hold back on this because it may just be
>something obvious or my limited understanding of how the polygon filter
>works.

If none of what I said above helps, feel free to send me your test case and
I'll see if there's something broken in the polygon code.  I keep meaning to
write a really good test case for it, but there are about three dozen possible
ways a test ray can cross a set of line segments, so it's been hard to quantify
them all.