I just spent several hours tracking down a problem involved in converting (RA,Dec)
values to pixel coordinates in SDSS images (DR7 vintage). A small fraction of the images
turn out to have the astrometry in their headers described in reverse order
(CTYPE1,CTYPE2 = Dec,RA instead of RA,Dec), so that if you create an astropy.wcs.WCS
object from the image header and call wcs_world2pix as e.g.
>>> wcsObj.wcs_world2pix([[ra, dec]], 1)
where ra and dec are decimal-degree values within the image, it interprets the input as
actually being [[dec, ra]] and thus gives you pixel coordinates for a position very
far away from the image.
So I wrote some code to check for this condition (e.g.,
if wcsObj.wcs.ctype[0] == 'DEC--TAN' )
and then manually reverse the order of (RA,Dec) when calling wcs_world2pix.
And then I went and re-read the wcs_world2pix documentation and noticed the
"ra_dec_order" parameter, which has the following description:
"When True will ensure that world coordinates are always given and returned in as (ra, dec) pairs, regardless of the order of the axes specified by the in the CTYPE keywords. Default is False."
Which leads me to a question and a possible bug report:
1. Why doesn't this default to True? It would seem far more useful and reliable
that way.
2. When I *do* call wcs_world2pix (or wcs_pix2world) with
ra_dec_order=True, wcs_world2pix fails with the following message:
AttributeError: 'astropy.wcs.Wcsprm' object has no attribute 'lattype'
This happens for WCS objects created from SDSS images with "normal-order" headers, too,
so it isn't just some peculiarity of the reversed-astrometry-order headers.
(Mac OS X 10.9.2 + Python 2.7.5 + astropy 0.3.1; also on Ubuntu Linux + Python 2.7.3 + astropy 0.3.1)
cheers,
Peter
=============================================================
Peter Erwin Max-Planck-Insitute for Extraterrestrial
er...@mpe.mpg.de Physics, Giessenbachstrasse
tel. +49 (0)176 2481 7713 85748 Garching, Germany
fax
+49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin