[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