[AstroPy] comments on coordinate system and wcs packages

Perry Greenfield 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  
examples.

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  
necessary?

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  
be great.

Perry




More information about the AstroPy mailing list