[fitswcs] Units along spectral axes
Mark Calabretta
mcalabre at atnf.CSIRO.AU
Fri Jun 10 02:53:51 EDT 2005
On Thu 2005/06/09 17:12:09 +0100, David Berry wrote
in a message to: William Thompson <William.T.Thompson.1 at gsfc.nasa.gov>
and copied to: FITSWCS <fitswcs at donar.cv.nrao.edu>
>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. So a non-standard units string
that comes out of the header may be fixed by passing it through this
filter before being analysed.
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.
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.
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.
I'd be happy to provide a pre-release of the parser and translator on
request.
Mark Calabretta
More information about the fitswcs
mailing list