[AstroPy] [astropy-dev] Coordinates subpackage - request for help

David Berry d.berry@jach.hawaii....
Fri Nov 16 01:55:06 CST 2012

On 16 November 2012 05:50, Demitri Muna <demitri.muna@gmail.com> wrote:
> Hi,
> On 15 Nov 2012, at 12:32, David Berry <d.berry@jach.hawaii.edu> wrote:
> I'm sure you didn't mean to suggest that astronomers only trust
> software written in IDL :-) AST has been around for more than a
> decade. It's based on the SLALIB library that was created by Pat
> Wallace, the author of the SOFA library (who was also involved in
> writing AST), and is used in very trusted tools such as DS9.
> No, not at all. But I know that a lot of astronomers live by it daily, and
> if we can say "this code agrees with what you are using to xxx precision and
> has been tested against it", it will assuage some.
> On 15 Nov 2012, at 12:27, Thomas Robitaille <thomas.robitaille@gmail.com>
> wrote:
> I think it would be great to have a PyAST version of the testing
> script in addition to the IDL one. I think it's fair to say that
> people trust AST (possibly even more than the IDL routines!).
> Yes, definitely. The IDL script can't be run automatically anyway.
> On 15 Nov 2012, at 22:24, Brandon Rhodes <brandon@rhodesmill.org> wrote:
> Several of the coordinate transforms mentioned in the post (maybe all?)
> are also implemented by the Naval Observatory's NOVAS library, which
> requires no license and for which they now support an official Python
> wrapper - though I will grant you that the API can take a bit of getting
> used to:
> Hopefully our API is better. :)
> So... can I get a volunteer to write the code that compares the results to
> the new astropy coordinates package? I might argue that it shouldn't be
> Adrian, Erik, or myself since we wrote the code, and it would be very
> valuable to have someone from the community use it to see how much sense it
> makes. This includes reading the examples and documentation to let us know
> if anything is unclear.
> Really appreciate all the help and suggestions.

I could do this (using pyast), but I think there are some issues to
resolve first - the main one being the question of "epoch" versus
"equinox". To get decent accuracy on FK4-FK5 conversions you need
both. I suggest the coordinates package is changed to rename "epoch"
as "equinox", and introduce a new "epoch" property to hold the date of


This may be re-visitiing old ground, but I can't help thinking that a
large amount of effort would have been saved (and maybe even still
could be saved) by implementing coordinates over the top of pyast.
After all, there are several other C libraries in astropy. It would
provide a guide to the meta-data required to describe each coordinate
system, it would give you immediate support for many additional
coordinate systems (ecliptic, FK4 with no E terms, geocentric apparent
equatorial, helioecliptic, equatorial referred to the  dynamical
equator and equinox of J2000 (not the same as FK5), supergalactic). It
would give you the ability to transform between horizon coords (Az,El)
and all other systems. When you come to extend astropy to include
spectral coordinates, it would give you immediate support for a
similarly wide range of spectral coordinate systems and
transformations between them. I've not looked at the current time
facilities in astropy, but pyast again would give you a wide range of
time systems too.

And it would provide a comprehensive system of stackable numerical
mappings, such as I was talking to Nadia Dencheva about at ADASS,
including the all-important ability to be able to simplify complex
mappings (by no means trivial).

And it would give you very versatile support for WCS, including
support for FITS-WCS and many "common but not quite FITS" headers, and
several common forms of distortion encoding (SIP, .

And it's all tried and trusted - anyone that uses DS9 uses AST.

I'll grant you the pyast API is probably not very astronomer friendly,
but implementing a simpler API on top of pyast may provide fast access
to lots of features. Looking at the astropy coordinates package, it
would probably have taken a day or two to implement it using pyast.



More information about the AstroPy mailing list