On 09/08/07, Peter W. Draper <[log in to unmask]> wrote:
> On Thu, 9 Aug 2007, David Berry wrote:
>
> >
> > Not with you. So when you come to write out the new FrameSet to the
> > FitsChan, how does the presence of PROJP keywords in the FitsChan
> > cause the output FITS header to be written in FITS-PC?
>
> It's not the write that's the problem, that's fine, it's the read when the
> FITS file is re-opened.
>
> Perhaps the title should be:
>
> Re: FITS-WCS written, but read back as FITS-PC.
>
> > Do you set Encoding before writing the WCS FrameSet out to the FitsChan,
> > or do you use the default?
>
> I set it to FITS-WCS.
>
> So (condensed headers from the files), initially I have:
>
> CTYPE1 = 'RA---ZPN' / Algorithm type for axis 1
> CTYPE2 = 'DEC--ZPN' / Algorithm type for axis 2
> CRPIX1 = 3.431523900000000E+03 / Dither offset Y
> CRPIX2 = -4.111654500000001E+03 / Dither offset Y
> CRVAL1 = 2.8992249E+02 / [deg] Right ascension at the reference pixel
> CRVAL2 = 1.5713925E+01 / [deg] Declination at the reference pixel
> CRUNIT1 = 'deg ' / Unit of right ascension co-ordinates
> CRUNIT2 = 'deg ' / Unit of declination co-ordinates
> CD1_1 = 2.0097707E-07 / Transformation matrix element
> CD1_2 = 5.5739441E-05 / Transformation matrix element
> CD2_1 = -5.5726214E-05 / Transformation matrix element
> CD2_2 = 2.7165242E-07 / Transformation matrix element
> PV2_1 = 1. / Pol.coeff. for pixel -> celestial coord
> PV2_2 = 0.000000E+00 / Pol.coeff. for pixel -> celestial coord
> PV2_3 = -50.
> PROJP1 = 1. /
> PROJP3 = -50. /
>
> which reads as a FITS-WCS. That WCS is then changed in GAIA to refine the
> positions, and re-written, as FITS-WCS (after a destructive read on the
> above) and becomes:
>
> CTYPE1 = 'DEC--TAN' / Type of co-ordinate on axis 1
> CTYPE2 = 'RA---TAN' / Type of co-ordinate on axis 2
> CRPIX1 = 150.0 / Reference pixel on axis 1
> CRPIX2 = 150.0 / Reference pixel on axis 2
> CRVAL1 = 15.8980643331 / Value at ref. pixel on axis 1
> CRVAL2 = 290.169112711 / Value at ref. pixel on axis 2
> CRUNIT1 = 'deg ' / Unit of right ascension co-ordinates
> CRUNIT2 = 'deg ' / Unit of declination co-ordinates
> PROJP1 = 1.0
> PROJP3 = -50.0
> NUMZPT = 6642 / Number of standards used
> CDELT1 = -5.59098742690742E-5/ Pixel size on axis 1
> CDELT2 = 5.59121728822906E-5 / Pixel size on axis 2
> PC1_1 = 1.0 / Transformation matrix element
> PC1_2 = -0.00442691692661737 / Transformation matrix element
> PC2_1 = 0.00212609392345515 / Transformation matrix element
> PC2_2 = 1.0 / Transformation matrix element
Surely this is a bug in AST???? In the text above the headers you say
that you re-write is as FITS-WCS, by which I presume you mean that you
set Encoding explicitly to FITS-WCS before calling astWrite. If so,
then why does the above list of headers contain FITS-PC keywords
rather than FITS-WCS? You're asking for FITS-WCS but getting
FITS-PC... I could understand this behaviour if in fact you were not
setting an explicit Encoding before calling astWrite, but if you *are*
setting Encoding, then it looks like a bug to me.
> so the PROJP1/3 keywords survive. Now when this latter header is read AST
> says ha, that's FITS-PC, not the FITS-WCS that was written, and uses the
> PROJP1/3 values and screws up.
>
> So what I'd like is to clean the first set of headers of all WCS related
> cards, and then write the FITS-WCS encoding, which would get rid of the
> PROJP1/3 cards, plus any other potential conflicts.
Yes, that can be done but I also want to make sure there are no other
bugs. Also, requiring an application to make an extra call to ensure
they get the correct encoding is not such a good solution as fixing
the problem in AST so that you get the correct encoding all the time.
The other issue is that doing a "spring clean" on other peoples
headers sounds a bit out of the FITS style.
David
|