[fitswcs] Units along spectral axes

[David Berry]

Mark,

> >3) Make the units handling software clever enought to recognise and
> >translate the bulk of the common units syntax variations.
>
> There is at least one other way - that adopted by WCSLIB v4.1 (un-
> released) whose units parser accepts only standard units specifications
> (well, almost).  That is to provide a separate translator for commonly
> used non-standard units specifications.

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.

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).

> There are several reasons for doing it this way:
>
> 1) Non-standard strings may be ambiguous, in particular because the
>    capitalised forms of 's', 'h', and 'd' (second, hour, day) conflict
>    with siemens, henry, and debye.  Interpreting 'S' as seconds rather
>    than siemens, e.g. in 'S', '/S' or 'KM/S', should be under user
>    control, as a translator option, not automatic.

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




> 2) If WCS information is written out it is far better for it to be in
>    standard form.  Hence WCSLIB now has a function to fix up a wcsprm
>    struct for all known non-standard constructions, including units.  At
>    some stage (rsn) it will also be given a function to write out a
>    wcsprm struct as FITS cards.

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?


> 3) Translating non-standard units strings is trivial (currently 37
>    comparatively simple flex rules - even a sed script would do)
>    compared to analysing a multiply parenthesised units expression (117
>    rules in a recursive flex scanner).  It's much better to put it in a
>    separate box.

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.



David