At present lsst.afw.coord contains a base class Coord, which arguably should be abstract, and subclasses IcrsCoord, FK5Coord, GalacticCoord, EclipticCoord and TopocentricCoord. Coord is duplicated by SpherePoint and of the subclasses we essentially only use IcrsCoord. Our table classes only hold IcrsCoord, reference catalogs must already use ICRS coordinates, our existing old Wcs classes assume ICRS, and our new SkyWcs class always uses ICRS, normalizing from other systems as required. I searched our code and found a few instances of FK5Coord that I'm pretty sure ought to be IcrsCoord. But aside from tests and examples I found no usage of any other Coord subclasses.
I propose the following:
- Eliminate all subclasses of Coord except IcrsCoord. Use AstroPy for coordinate conversions (or SOFA if desperate for speed).
- Eliminate Coord. Replace existing usage with IcrsCoord or SpherePoint, as appropriate.
- Unify IcrsCoord and SpherePoint:
- Presently there are similar methods with different names. Pick one.
- Make IcrsCoord immutable, like SpherePoint.
- Eliminate the "epoch" field of IcrsCoord. It was used for the date of equinox of FK5Coord and is no longer appropriate. It could be used for date of observation, when handling proper motion, but there are other ways to handle that.
- It should be trivial to construct an IcrsCoord from a SpherePoint and vice-versa. I suggest that each have a constructor that takes the other.
- Eliminate IcrsCoord's handling of angles as strings. Leave that to AstroPy.
- IcrsCoord should not inherit from SpherePoint, or vice-versa, in order to avoid mixing the two. In other words one should not be able to compute the angular separation between a spherical point and an ICRS coordinate, nor should a spherical point and an ICRS coordinate ever compare as equal.