Subject: [ggl] Clipping (i.e. intersection) issues, still.
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-07-06 05:04:21
Hi list,
>
> There is still polygon-box intersection isues, unfortunately (with SVN
> revision 869, at least).
It turned out that it is the direction. If polygons are directed
counter-clockwise, the generated intersection is the outside of that
polygon with the inside of the box. Which is theoretically correct by
the conventions we made. But it is of course not the intention.
OGC defines that all polygons are directed clockwise, holes (interior
rings) counter-clockwise.
There were earlier discussions about this on the Boost List, and I
mailed with Bruno about this.
There are the following solutions:
1) As it is now. Users (Chris) can correct polygons before using the
"ggl::correct" function which exists for this purpose. Correct sets the
exterior ring clockwise, the interior rings counter-clockwise.
2) The intersection and union_ algorithms can check if the polygons are
oriented OK, and if not reverse them. Library users don't have to do
anything. The problem is that this is not the only algorithm assuming
the clockwise orientation, so if we do it here, we should do it
everywhere, making (in most cases) unnecessary checks and often copies
again and again
3) Implementing the orientation in the polygon traits class. It is then
known at compile-time which orientation the polygons have. For this
case, it is not a solution because the library user does not know before
hand which orientation the polygon has.
4) Implementing the orientation in the polygon traits class as a
three-state option: clockwise, counter clockwise or
undetermined/both/unknown. The library can then handle it accordingly,
only making the check in the last case.
5) As 2, but with an (optional) bool parameter indicating that the check
has to be done. This is a sort of temporary solution
...) maybe there are more solutions.
Solution 4 is probably the most generic and convenient. However, I would
propose that, if we decide for that, to postpone that one because we've
more to do for preview 5.
Chris, can you live for the moment with solution 1)? It means to call
"ggl::correct", meaning that you probably have to make a copy, or call
that immediately after the user edits the polygon, or whatever is
convenient?
Otherwhise we could think about 5) which is also feasable in a limited time?
Regards, Barend