[fitswcs] Units along spectral axes

[Mark Calabretta]

On Fri 2005/06/10 09:49:05 +0100, David Berry wrote
in a message to: Mark Calabretta <mcalabre at atnf.csiro.au>
and copied to: William Thompson <William.T.Thompson.1 at gsfc.nasa.gov>,
      FITSWCS <fitswcs at donar.cv.nrao.edu>

>I wasn't implying where the cleverness should go. However, from the user
>convenience point of view, having the units cleverness built into the
>WCS software means they do not need to poke about inside the header,
>parsing cards, etc, themselves. Having options within the WCS system to
>tune different levels of tolerance to deviant units would be one way of
>dealing with the ambiguous unit problem (using "A" for Angstrom instead of
>Ampere is another case). Providing some sort of "unit translator plugin"
>facility would be another.

David,

Using functions added to WCSLIB in recent times it's basically become a
three step process: 1) feed the FITS header into the WCS header card
extractor to get an array of up to 27 wcsprm structs, 2) (optional but
probably inevitable) translate non-standard constructs in each of the
wcsprm structs, 3) use them to do coordinate calculations.

The question of what goes into the units translator is open, inevitably
everyone will end up with an idiosyncratic list simply because non-
standard units specifications are non-standard.

>This is probably not appropriate for WCSLIB though, in that, as far as I
>understand it, "purety" is a design goal for WCSLIB. That is, it doesn't
>attempt to interpret existing devient WCS in the same way that AST or
>WCSTOOLS does (for which reason I'm a bit suprised by the "well almost"
>in your message).

The "pure" part of WCSLIB is still as pure as ever which actually is at
least a little impure.  For example, in the past it recognized -NCP and
-GLS and translated them silently into -SIN and -SFL for internal use,
but the translation only affected the lower level prjprm struct.  Now if
you apply wcsfix() the effects are visible at the topmost level of the
wcsprm struct, e.g. the relevant ctype[] array elements are translated
and, for -NCP, two pv[] array elements are added.  Much the same applies
for the older AIPS-convention spectral types, e.g. 'FELO-HEL'.  This
really only matters if you write the wcsprm struct out.  However,
wcsset() now forcibly translates standard celestial and spectral units
specs to deg and SI, which, at least for the celestial, is an
extension of the standard.

The "well almost" was simply that I added 'angstrom' and 'ohm' (aka
'Angstrom' and 'Ohm') which went most of the way to supporting the OGIP
spec - only 'Crab' and the exotic function types remain unsupported
essentially because they are not well defined.  In other words, you
get this modest level of units specification translation automatically.

>In pratice of course, astronomical WCS information rarely refers to
>siemens, henry, or debye (or ampere).

Undoubtedly true, especially for images, but still it has to be the
user's responsibility.

>Will the use of this fix up function be a mandatory step in producing a
>header? Whilst I'm obviously in favour of encouraging conformity, I'm not
>sure Zero Tolerance is appropriate (e.g. people may want to produce
>deviant headers for the benfit of local legacy software). Is there a
>problem in providing an option for explicitly supressing the unit fix up?

wcsfix() is actually a driver for five separate translator functions
(date, units, celestial, spectral, and malformed cylindrical projection)
each of which may be applied separately.  However, in writing out a
header I think WCSLIB will probably have to enforce the standard except
in cases where it can be written completely without using any new
semantics - and CUNITia itself is new semantics.

>The actual translation of the strings is not a big problem, but finding
>the string, extracting it and then replacing the translated string can be
>a burden for software which would otherwise have no need for poking about
>inside a FITS header. I'm used to writing application software which never
>touches WCS headers, either for reading or writing. This is why a allowing
>a unit translator plugin to be registered with the WCS software could be a
>good idea - the WCS software does all the header management stuff,
>extracts the devient string from the card and feeds it to the translator.

The WCSLIB units translator deals with C strings so could be used to
fix a FITS header if you wanted but that's not what it's intended for -
I don't think there's much point trying to fix existing FITS headers
(surely a futile exercise).  Together with the other translators it's
meant to fix a wcsprm struct - essentially it's a preprocessor.

Mark Calabretta
ATNF