is_clockwise() returning False if points on a great circle, whatever orientation chosen

[almicol]

Hi Bernie,

I noticed that the is_clockwise() function will return False (hence CCW)
for both these two polygons:
A: (0, 0) (90, 0) (180, 0) (270, 0) (360=0, 0)
and
B: (0, 0) (270, 0) (180, 0) (90, 0) (0, 0)

Given that one is the inverse/complement of the other, they cannot be both CCW.

In particular, A is CCW (correct? I think so, given the right-handedness of the equatorial system), and B then is CW.

The issue comes from the fact that when all polygon's vertices are on the same great circle the triple_product (B-A, C-B, B) is always 0. Hence, any polygon inscribed in a great circle will always give this same headache.

PS: The definition of CW/CCW is what matters to me, and this is why I'm writing here.
How is CW/CCW defined when all vertices of the polygon are on the same great circle?
The VO STC standard is not precise about this (it only mentions a "left" direction when following the polygon, leaving in the air the definition of "left", making impossible to define the handedness for all great circles). A possibility is that we indeed leave the handedness of any great circle undefined... in which case is_clockwise() should return None and not False for the two cases provided above. Any clarification is MORE than welcome!

Thanks a lot,
Alberto

[bernie-simon]

This is a difficult problem.

First, please note that whether the polygons are ordered clockwise or counter-clockwise depends upon the choice of the interior point, either the north or south pole. Without the choice of an interior point the question is undetermined.

The current code in is_clockwise does not take account of the interior point and instead only takes account of the handedness of three consecutive points. In the case where the three points are co-linear, the handedness is undetermined, as you have noticed. I've tried code in the past that has used the interior point. Even though this may be preferable from the theoretical perspective, it suffers from the problem that the polygon constructor calls is_clockwise before it has determined the interior point. While the code in is_clockwise works well in the typical case used in astronomy, there are cases where it does not. But I have to consider how the whole package works and the current code is the best compromise I have come up with.

[mcara]

@pllim Why do you think this is a bug?

[pllim]

@mcara , based on this comment by Bernie above, "While the code in is_clockwise works well in the typical case used in astronomy, there are cases where it does not."