Problems with RA,Dec order when calling WCS.wcs_world2pix

292 views
Skip to first unread message

Peter Erwin

unread,
Apr 11, 2014, 11:12:09 AM4/11/14
to astro...@googlegroups.com
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



Michael Droettboom

unread,
Apr 11, 2014, 11:20:27 AM4/11/14
to astropy-dev
On Fri, Apr 11, 2014 at 11:12 AM, Peter Erwin <peter...@gmail.com> wrote:
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.

Mainly it's because that behavior would differ the WCS specification -- which says that the ordering of RA and Dec are defined in the file.  If working with one's one data, one may put them in that order for a reason (i.e. it's the natural order of an internal data structure) and we wouldn't want to flip it implicitly.  

As astropy.wcs is a wrapper around wcslib, we try to follow its behavior as closely as possible by default to make it easier to port code over to Python.  Note that RA and Dec are not the only coordinate types -- there are spectral coordinates as well, and all can be in arbitrary order.
 


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 is a known bug, fixed in #1463.

 

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.

I'd recommend upgrading to the 0.3.x branch of astropy from git -- 0.3.2 is planned to be out in the not-too-distant future.

Mike
 

(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



--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Michael Droettboom


Reply all
Reply to author
Forward
0 new messages