Very nice work – clean, well tested and well documented code. I put comments on github. A few I'll repeat here:
Please add an atPole method. I suspect the test should be latitude within epsilon of pi/2, rather than latitude not less than pi/2 based on two considerations (both of which may be wrong):
- Getting reliable results from offset and rotated, even in extreme cases.
- Being able to generate a point at the pole by providing a latitude specified in degrees or arcseconds.
Allow longitude and latitude to be nan. Two important use cases are:
- representing invalid values input to output from transforms
- representing unknown boresight az/alt in VisitInfo
I suggest that a point with a latitude of nan not be considered to be at the pole, so operations such as offset do not raise an exception. That will affect how atPole is implemented.
I also suggest allowing +/-inf for longitude, not because I have a specific use case, but primarily for self-consistency: I think it would surprise users to be able to specify nan but not inf for longitude (clearly it is invalid for latitude). If you prefer to disallow it, that's fine.
Please consider allowing nan in arguments to methods such as offset, to allow quiet propagation of nan when appropriate. The need is less obvious than for nan longitude and latitude, but it enhances self-consistency.
Please consider adding an isFinite() method that returns true if and only if longitude and latitude are both finite (a request I did not make on github). I realize that classes such as Angle and Point do not have this, so feel free to reject this suggestion if you'd rather not add the method.
In my opinion you should feel free to rename the class to SpherePoint or SphericalPoint or retain SphPoint, as you prefer. I think they are all sufficiently clear and unambiguous.