I will start a discussion here since this doesn't relate to the API.

It would be good if this proposal states how this package relates to a WCS package/functionality.
To me it looks like the low-level classes (subclasses of CoordinateFrame) fit well with the description of the WCS object discussed before where subclasses of CoordinateFrame (without the data) are what the WCS object refers to as SkyFrame. Is this correct?

Can you also clarify what the role of SkyCoordinate is? Is this what the data attribute of NDData will be (I may be interpreting this incorrectly)?

The APE says that SkyCoordinate may be extended for systems that are not celestial coordinates. I think this means that CoordinateFrame must be extended to include non-celestial frames as well. This is similar to what the generalized WCS proposal is (but perhaps I'm still thinking in terms of the WCS proposal and this is different). If so it is important to see what the base class CoordinateFrame looks like since it must be easy to extend it.

In general how does this relates to the coordinate_system attribute of the generalized WCS?

@nden - I see your point that CoordinateFrames without data and SkyFrame are very similar in concept. So this gives me hope that this is a good place to use to connect the two together... I'll have to think a little bit more in detail how this might actually be done, but as I said on-list (where I think more discussion on this will be taking place), I would prefer to have APE5 focused on the coordinates API rather than much detail of how it interfaces with WCS.

As for SkyCoordinate, its main role is as just what's described here: it's a container for the other classes that provides more generalized user-friendly interface items (e.g. parsing and output of obscure/complex coordinate strings), as well as storing data on the frame that is not necessary for the current system, but may be to be able to round-trip. E.g., equinox is not necessary for ICRS, but if you want to do FK5->ICRS->FK5, SkyCoordinate would store the equinox even when transformed to ICRS.

And when I meant non-celestial coordinates, I did not mean the full WCS sorts of options - rather, other forms of spatial coordinates that are not celestial per se, but that one might want to hook into the trasnformation graph. The most critical example here is ITRF/ITRS, the reference system for points on the surface of the earth, as that's necessary for getting from ICRS to AltAz. But that's not a "celestial" system by definition. But to reiterate, I do not mean that this system will eventually be expanded to include dispersion/temporal coordinates as it's firmly in WCS territory.

Does that all makes sense? If so, I can try to clear some of this up in the APE text itself.

@eteq This makes sense. Thanks for the clarification.

No objections have been raised for the merging of the APE, so going ahead and merging it! The API may require one final iteration before it is merged.