> But its a bit like the situation with the old AIPS WCS keywords - they
> were in common usage, but they had never been precisely specified.
Yeah cf. recent fisbits discussion on CROTA1 versus CROTA2.
> Are we sure that all packages which use more.fits use it in the same
> way? In some places I have seen it stated that more.fits is simply for
> keeping a record of the FITS headers as they existed at the time the
> NDF was created.
That was the original plan. Other metadata would be imported into
NDF components and more-specific extensions whose meaning was specified.
In FITS the semantics are not well defined apart from a small
number of keywords. Even then there is confusion, such as EXTNAME
being used for a type rather than an extension name, in CFITSIO.
In practice, however, we saw that users weren't adopting this approach,
and wanted to treat the FITS extension as a dynamic entity.
Astronomers were more familiar with FITS headers than HDS structures.
We relented. The onus of interpreting the headers was placed upon the
user. If the user wanted an exposure time, say, they had to know which
keyword was appropriate and the units.
NDF2FITS does re-export the headers, but excludes information superseded
by that from standard NDF components like the WCS, array dimensions.
NDF2FITS attempts to take a pragmatic approach and only specifies a few
tens of headers from NDF standard properties and components. Some
metadata may now be invalid because the user hasn't fully maintained the
FITS airlock during processing. That's a penalty for relaxing the
original design. One example springs to mind: DATAMIN and DATAMAX in
the original headers are likely to be invalid.
The apparent conflicting descriptions most likely reflect the time that
they were written. It does mean that people and software may just treat
it as a record of the original FITS headers, even though the majority
treat it dynamically (including ORAC-DR).
You actually could do with both approaches: a copy of the original
headers and a working area for metadata. Then there's the question of
what to do with the original metadata on export. Would you merge the
two headers, taking priority from the dynamic set? You can't even
simply flag and protect metadata that should never change, reflecting
the original data collection, state of the instrument, meteorological
information etc. because at the observatory/data centre you may need to
correct erroneous or supply missing information.
> fits airlock idea becomes part of the NDF standard. Also of course the
> airlock component would need to be moved from MORE otherwise it really
> would break the philosophy that MORE is used for stuff which is not part
> of the NDF standard.
Agreed. That would require many code changes and we'd have to provide
support and migration for existing NDFs with a FITS airlock.
> > 2. kaplibs is a bit of a hodge podge and has far more dependencies
> > than NDF. Writing a perl wrapper to this routine is easy if it's
> > in NDF. I'd be happier with ndfGtfts in KAPLIBS if the NDF
> > bits of kaplibs were spun off. I also don't really like the "1"
> > in all the method names and think we should start using "kpg"
> > rather than "kpg1".
>
> I agree that kaplibs is becoming (or is already) a bit of a black hole and
> that ideally it should be split up and tidied up. But the question is
> whether it is worth the time given the other jobs we're all doing.
The 1 notation is historic for internal routines, and yes it should not
be in a public API. While we could change all our code fairly easily,
what of external programmers? The time to rename was when KAPLIBS
became public, no longer internal to KAPPA.
Tim likes rationalising, perhaps he can fragment KAPLIBS. (-:
> > I'm clearly not going to win this one though...
>
> We're always open to persuasion...
Yes, and the second message was far more persuasive than the first.
Malcolm
|