In SIN projection, astropy.wcs makes RA=0 line point up at the North pole

Description

When using astropy.wcs to get coordinates for a pixel from an observation targetting the North Celestial Pole (NCP), with a SIN projection, astropy.wcs incorrectly interprets the keywords such that the RA=0 line points up. As a result, the coordinates produced by astropy.wcs are 180 degrees rotated compared to the real sky.

The SIN projection is the default for radio-interferometric imaging. Of course, part of the confusion comes from the fact that it isn’t super-clearly defined what’s up in a NCP image: for any other direction on the sky, up is towards the NCP.

Expected behaviour

Conventionally the RA=0 points down in images at the NCP (at least in my field), and this is as far as I understand also according to the FITS standard. E.g., Figure 3 in Calabretta and Greisen (2002) shows exactly that; the projection at the pole with RA=0 pointing down. That Figure is not yet in the generic SIN projection, but the SIN projection calculations are based on the earlier projections defined in that paper, which follow this figure.

I noticed that ds9 also reports the wrong coordinates, probably because it uses libwcs. Casacore and kvis produce the right coordinates. CASA (which makes use of Casacore) does have issues imaging the NCP and puts the RA=0 line up.

I’m author of an interferometric imager, and have received a few bug reports concerning the issue, the latest here: https://gitlab.com/aroffringa/wsclean/-/issues/124. The imager itself however does not decide if RA=0 is up or down at the pole; this is determined from the “UVW” coordinates in an observation, which are often calculated by the Casacore library. It’s not impossible that Casacore is at fault instead of astropy.WCS, but given the arguments above I believe it more likely to have the RA=0 line be downwards at the pole.

I’ve only tested the NCP, and don’t know if there is also an issue at the SCP.

Steps to Reproduce

The program below can be used to calculate the position of 3C 61.1 (a strong radio source near the pole) in a specific fits file with SIN projection, centered on the NCP. This FITS file can be used as input: http://www.astro.rug.nl/~offringa/ncp.fits . The correct output would be (close to) 35 degrees RA and 86 degrees Dec, whereas WCS reports RA 215 Dec 86.

from astropy.io import fits
from astropy.wcs import WCS

def print_3c61(filename, x, y):
    f = fits.open(filename)
    w = WCS(f[0].header)
    sky = w.pixel_to_world(x, y, 0, 0)
    print(filename + " : " + sky[0].to_string())  
    f.close()

print_3c61('ncp.fits', 256, 148)

Some of the relevant headers of the NCP fits file:

EQUINOX =                2000. / J2000
[..]
CTYPE1  = 'RA---SIN'           / Right ascension angle cosine
CRPIX1  =                 513.
CRVAL1  =                   0.
CDELT1  = -0.00833333333333333
CUNIT1  = 'deg     '
CTYPE2  = 'DEC--SIN'           / Declination angle cosine
CRPIX2  =                 513.
CRVAL2  =                  90.
CDELT2  =  0.00833333333333333
CUNIT2  = 'deg     '
[..]
SPECSYS = 'TOPOCENT'

System Details

Linux-5.18.0-3-amd64-x86_64-with-glibc2.33
Python 3.10.5 (main, Jun  8 2022, 09:26:22) [GCC 11.3.0]
Numpy 1.21.5
pyerfa 2.0.0.1
astropy 5.1
Scipy 1.7.3
Matplotlib 3.5.2

[keflavich]

I think that means that you consider a WCS incorrectly / under-specified if it needs LONPOLE and doesn’t have it. So this is on the FITS file writer to get right.

However, we might add a check about the presence of LONPOLE if the coordinates include the NCP?

[pllim]

Thanks for the report!

@keflavich , since you are familiar with CASA, what is it doing right that we’re not doing here? Is this something we need to report to WCSLIB?