On 09/08/07, Peter W. Draper <[log in to unmask]> wrote:
> On Thu, 9 Aug 2007, David Berry wrote:
>
> > I've changed fitschan.c so that the algorithm that
> > chooses the default encoding ignores keywords like PROJP unless there
> > are also some CRVAL, CRPIX and CTYPE keywords in there. This means that
> > when GAIA writes out the fits header for Bringfried's data, it should
> > return a default encoding of NATIVE. Presumably you check for NATIVE,
> > and if found, set an explicit value of FITS-WCS instead?
>
> Don't think that's quite what I'm after. The default encoding for writing
> is the one that the first read of the channel returns (presumes your
> favourite). In this case yes it's FITS-WCS (and yes if I see a native
> return for a FITS file I switch that to FITS-WCS, but only if it's the
> first).
>
> The problem is that because the FITS headers contain information about one
> WCS, but in different possible co-existent encodings (which I presume are
> initially consistent), a read using FITS-WCS leaves the cruft in the
> channel. I try to read another WCS at this stage, but that rarely works
> (except when we also have a completely non-standard encoding somewhere,
> like DSS or native).
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? Do you set
Encoding before writing the WCS FrameSet out to the FitsChan, or do
you use the default?
David
>
> So what I really need is a function that cleans all possible WCS related
> cards from the FITS channel (after the first read) so when I write the new
> one (plus sometimes a native encoding, but that's happily orthogonal),
> that's guaranteed to be what is used by all subsequent software.
>
> Make sense?
>
> Peter.
>
--
Note my change of e-mail address. Please send e-mail to
[log in to unmask] from now on.
|