Fix Version/s: None
skyMap behaves wrongly around ra = 360^\circ. For example, the following assertion does not hold:
This bug is causing detect_isPrimary = false for all objects around ra = 360^\circ .
I have no idea what's the very cause of this bug, but at least the following lines are wrong:
When ra - self.config.raStart is near 2pi, tractNum will be 1 plus its maximum permitted value, which results in the returned tract located in the northern ring.
EDIT: This is incorrect. The truth is tractNum starts with 1. And it's not " ra - self.config.raStart is near 2pi" but " ra - self.config.raStart is near 0" that is problematic. --End EDIT
It should also be warned that math.fmod() in python behaves just as fmod() in C. It returns negative value when ra - self.config.raStart < 0 . In that case int(... + 0.5) should be int(... - 0.5) (But I suggest using a homemade fmod that would always return positive value) (edited)
The fmod() misuse is irrelevant to the current problem because self.config.raStart = 0 for now.
RingsSkyMap.getRingIndices() also behaves wrongly around the south pole.
Let the return value (ringNum, tractNum).
tractNum usually starts with 1.
But from getRingIndices(index=1) is returned tractNum = 0 .
As a result, the 0-th ring has 11 tracts while self._ringNum=10 ,
and skyMap and skyMap are exactly the same.
We need to fix these problems without renumbering all the tracts because there is existing data that we don't want to invalidate.