[AstroPy] comments on coordinate system and wcs packages
perry at stsci.edu
Fri May 4 13:34:37 EDT 2012
To add to the discussion a bit.
First, addressing AST. There seem to be two separate thoughts on this;
one is that AST should be adopted as is (made the underlying basis for
an astropy library) and the second is that it's interface should be
considered for any library constructed for astropy (but that the AST
implementation itself need not be adopted).
To start, I'd like to say that the AST design is far more flexible
than most of the other libraries out there (that I'm aware of anyway).
Yet, I would like some different approaches for astropy (I only speak
for myself here, by the way).
I'll only mention a few reasons why today. I think the primary general
one is that I think AST bundles together a number of things that
should have separate and distinct functionality within astropy. This
is both an implementation and an interface issue. I'll call out a few
The first is units. Unit handling appears to be embedded within AST.
Yet units have many other uses outside this framework. So at the very
least, a units module has to be separate.
The second is that coordinate systems are an intrinsic part of the
system (essentially everything derives from frame). Again, the mapping
aspect doesn't necessarily need to be tied to any particular
coordinate system. It's not uncommon for WCS definitions to be
essentially agnostic about what coordinate system they are using since
the most important problem is regarding relative coordinates. Arguably
any sky coordinate system would do. Sure, one could then pick any and
use it consistently. But why involve that machinery if it isn't
So I would see mapping as a distinct entity from frames. Frames use
mappings, but mappings don't inherit from frames. (We've been calling
them transforms locally.) I tend to see the equivalent of frames as
using units and mappings for various operations (but again, is the
intrinsic definition of a frame unit based? Aren't units only for
input and output of coordinates? Arguably the intrinsic sky coordinate
is unitless, or at least a consistent internal system should be used
for sky coordinates (e.g, degrees or radians; or perhaps even better;
unit sphere vector coordinates).
Another reason to keep mappings separate is that they have more
general applicability than do frames. Our goal is to have a mapping
framework that integrates well with fitting tools, and at the same
time is as decoupled from fitting tools as possible. I don't see that
this is currently in the AST framework. For WCS, fitting is a big
issue, and pretty intertwined with how WCS models are determined.
Finally, there are various complexities of how to interact with FITS
files as regards WCS models. There is no single approach that
satisfies all needs. I don't think the AST approach solves this issue
well enough either. A lot could be written on this single point, which
I won't here, but I won't be surprised if I'll be required to. ;-)
We have been working here at STScI on dealing with WCS aspect of this
approach (particularly with regards to mappings, fitting, and how to
deal with FITS). We haven't done much with the coordinate frame issues
(they aren't as urgent). Integrating the two in a flexible way would
More information about the AstroPy