Geometry Boost List: [ggl] Clipping (i.e. intersection) issues, still.

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