Mark,
The published form of FITS-WCS paper 2 does not allow any PVi_j
keywords to be associated with the latitude (i.e. DEC) axis of a TAN
projection. Since the DEC axis is axis 2 in the supplied header, this
means that keywords called "PV2_m" (for any integer m) are not
allowed. There are two possibilities of what the author may have been
intending by including the PV2_3 keyword in the header:
1) A draft version of paper 2 allowed PVi_j keywords to be associated
with both RA and DEC axes of a TAN projection, and used them to specify
a distortion to be applied to the projection. Some data did get
created that used this draft convention, but the convention was removed
before the paper was finally published. AST still supports this convention
on the basis that, since the published paper does not allow TAN
projections to have PVi_j terms associated with the latitude axis, the
presence of such keywords in a header implies that the earlier draft is
being used, rather than the published paper. So GAIA/KAPPA etc will see
the PV2_3 keyword, assume therefore that the old draft convention is being
used, and apply a suitable distortion to the projection. The problem is
that the value assigned to the PV2_3 keyword in this particular
case (220.0) is really wacky and produces ludicrous distortion. For this
reason, I suspect that the following second possiblity is more likely...
2) I think the "PV2_3£" keyword should really be "PV1_3". It gets a bit
complex here, but the published paper allows "PVi_3" (where "i" is the
index of the longitude axis, 1 in the case of the header in question) to
be used in place of the LONPOLE keyword. LONPOLE is a rotation angle in
degrees, and "220.0" (the value of "PV2_3") looks eminently believable as
a rotation angle in degrees.
So, because the PV2_3 value (220) does not look believable as a distortion
term, we must assume that either a) the author was completely up the spout
and just included the keyword for fun (in which case simply delete it from
the header), or b) the PV2_3 value indicates a rotation angle and so
should be renamed as PV1_3.
The problem is that these two courses give completely different coordinate
grids. So it is fairly important that the user somehow tries to determine
which assumption is correct.
David
On Thu, 10 Aug 2006, Mark Taylor wrote:
> David,
>
> Rhys Morris is having trouble with some FITS-WCS headers.
> The file is at
>
> ftp://andromeda.star.bris.ac.uk/pub/star/data/2336+56_ha-r_mosaic.fit
>
> Attempting, e.g. to draw a grid over it in GAIA doesn't work, and
> if you look at the reported RA values when moving the cursor over
> different parts of the image you can see that it gets pretty
> confused. DS9 coordinate readout appears to be sensible, though
> again trying to plot a grid gives an AST error.
>
> If I remove (well, rename) the card
>
> PV2_3 = 220. /
>
> then the WCS looks fine, though I don't know whether it's correct or not.
>
> I don't know what the PVi_j cards are supposed to do. Can you comment
> on whether this is broken FITS-WCS (which I expect is the case), or
> a problem in AST, or something else, and/or speculate about what
> the file's author meant to say?
>
> thanks
>
> Mark
>
> --
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> [log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>
|