As discussed with @eteq and @keflavich

In the APE 14 API, we currently use SkyCoord as the high-level object for celestial coordinates, but we only use Quantity for spectral coordinates, without any attributes that describe the frame of reference the spectral quantity is in, meaning that we can't easily convert between different spectral representations. The solution is to develop a SpectralQuantity that subclasses Quantity and adds metadata about the spectral frame as well as conversion functionality. This is best developed in specutils to start with for faster development, and we can incorporate it in to astropy core later.

SpectralQuantity should have the following attributes:

• frame=: this would be a BaseFrame object
• rest=: a quantity giving the rest wavelength or frequency (assuming the same frame etc. as the parent quantity)
• type: radio_velocity, optical_velocity, frequency, energy, wavenumber, air_wavelength, etc.

In addition, we should make sure SpectralQuantity(SpectralQuantity(...), …) should work (needed for APE 14) and convert the spectral coordinate, as should e.g. SpectralQuantity.to(..., frame=’...’, type=’...’).

Any of the attributes can be passed into the constructor as None, in which case it basically just behaves like a normal Quantity. But if they are not None, to does smart things where possible and raises exceptions if anything would be inconsistent(i.e., to(u.um, type=’velocity’)).

We also decided that information about bin edges doesn’t belong inside this class - instead either there could be a SpectralAxis class that subclasses SpectralQuantity, or that contains e.g. a SpectralQuantity for the bin edges.

One item that still needs to be discussed is where to keep information about the direction of the observations - needed when transforming frames. One option is to include it as an attribute of the SpectalQuantity, and another option is to pass it as an argument during the transformation.

This should be developed in specutils in a file that should be well isolated from the rest of the code and could easily be moved to the core package once we are happy with it.