[AstroPy] comments on coordinate system and wcs packages

[David Berry]

Hi All,
         I've probably done most of what's useful now in terms of
presenting the AST model as a tried and tested, very flexible and
easily extended coordinate handling paradigm. Obviously it's up to you
guys to make the decisions since I'm only an interested bystander.

There's an awful lot more that could be said about the things AST
does, and why. The one big problem with it is that for historical
reasons it is a monolithic system. When we first started on AST about
20 years ago, object-oriented languages were not common in astronomy.
There was a bit of C++ around, but the main author (Rodney
Warren-Smith) decided that to promote it's take up, we would write it
in pure ANSI C. This meant he first had to write an entire OO
infrastructure system to support inheritance, encapsulation,
polymorphism etc. which he did quite effectively. But that has meant
that the only way to extend AST is by adding new classes to AST
itself. Which is why AST gives the impression of doing "everything".

Nowadays, with Python, Java, etc being so common, we would have done
it differently. And indeed I think it's a good idea to look at Mapping
as a separate and more fundamental thing. Then have Unit as a class
that can do things like returning a Mapping between two unit strings.
Then have a hierarchy of Frame classes, each with built-in knowledge
of the various specific coordinate systems that can be used to
describe a single physical or mathematical space, and with the ability
to return a Mapping between any two such coordinate systems. And then
have a FrameSet which represents a collection of Frames connected
together by Mappings.

The only reason we made Frame inherit from Mapping within AST is that
we did not have any way of doing multiple inheritance or Java-like
interfaces using the OO infrastructure Rodney had written. We wanted
FrameSet to inherit from both Frame and Mapping so a FrameSet could be
used either as a Frame - it's "current" Frame, or as a Mapping - the
Mapping from its "base" Frame to its "current" Frame. With modern OO
languages there is no real reason to make Frame inherit from Mapping.

On the issue of units though, I must have a blind spot. Surely units
are a fundamental part of coordinate handling? Every axis within a
coordinate system has some units, so how can you work out mappings
between frames without taking the axis units into account? If you have
a frequency axis in GHz and a velocity axis in km/s, then in order to
get a Mapping between them you need to know what "GHz" and "km/s"
means, and how to transform them into other things. It's an implicit
part of coordinate handling. That's not to say that the Frame class
could not call out to a separate Unit class to get the required
transformations though.

Regarding FITS WCS, I've long held that it's unnecessarily
restrictive. AST is much more flexible, and has it's own textual
format for storing and retrieving WCS in data files that can handle a
much wider range of transformations that FITS-WCS. But obviously
everyone wants to use FITS, so AST contains a translator class
(FitsChan - it's what DS9 uses for reading FITS-WCS . The problem is
that many of the FrameSets that AST can create and handle cannot be
represented in FITS. Perry - I'd be interested to hear what your
concerns are about FITS-WCS.

Anyway, as I said at the beginning, I've probably said as much as (or
more than) is useful on the subject of why AST is a good model for
coordinate handling. In summary, it just works!

David


BTW - RA and Dec are tied together into a single Frame because you
wouldn't otherwise be able to  move around in a (RA,Dec) coordinate
system or transform an (RA,Fec) position into (e.g) galactic coords
without knowing about the spherical nature of these coordinate
systems.