Russell Owen, I was looking at this in connection with DM-5529, and there's a problem: Coord::transform accepts two arbitrary Coords, and returns a newly constructed Coord. From the documentation for this method, it's not possible to make it return one of EclipticCoord, Fk5Coord, GalacticCoord, IcrsCoord, or TopocentricCoord – there needs to be a "generic coordinate system" class to support arbitrary arguments to transform.

I propose that abstracting Coord be moved from DM-5529 to here, as it's a nontrivial change, and that creation of a new subclass (GenericCoord?) with capabilities similar to the current Coord be included as part of this ticket.

EDIT: actually, now that I think of it, it's not really clear how transform should be defined for subclasses of Coord... what happens if poleTo is of a different type, for instance?

I agree that making Coord an abstract base class should be moved to a new ticket and implemented only after SphPoint is available.

I suspect we may never make Coord an abstract base class. It is more likely that Coord will end up being a single class that contains a SphPoint and some metadata (e.g. the coordinate system and epoch), and that it will lose its ability to transform between coordinate systems or use AST internally to provide that ability.

Meanwhile, best to implement SphPoint and leave Coord alone.

To second Russell Owen, during the Astropy discussions we came to the conclusion that the C++ code never does coordinate conversion so there is no reason to support Galactic, Ecliptic, FK5 and the rest. If you want conversion you can do it in Python with Astropy. When I ran the astropy coordinate conversion comparison routines (which checks many different libraries) the LSST code was not that great (especially for Galactic).

Implemented as part of DM-11162 eliminate the Coord classes