[fitsbits] Primary & Alternate WCS Keyword Order

Lucio Chiappetti lucio at lambrate.inaf.it
Mon Jun 25 06:46:35 EDT 2012


I confess I overlooked the existance of the WCSAXES keyword. Probably I 
always encountered/used cases where WCSAXES silently defaulted to NAXIS.

The text in 8.2 says:

WCSAXES – [integer; default: NAXIS, or larger of WCS indexes i or j]. 
Number of axes in the WCS description. This keyword, if present, must 
precede all WCS keywords except NAXIS in the HDU. The value of WCSAXES may 
exceed the number of pixel axes for the HDU.

Now (I haven't checked the original WCS papers):

  - I can't image a case where WCSAXES > NAXIS
  - I (can) hardly imagine WCSAXES < NAXIS (maybe a datacube where X,Y are
    sky coordinates, and Z is a conventional coordinate, or alike)

  - but how can the default be established as an "or" condition ?

    default: NAXIS,                     (ok, NAXIS comes first)
    or larger of WCS indexes ior j      (means reading the Cxxxx kwds !)

In general, I think we should avoid as far as possible positional 
constraints on header keywords. In modern world, we should think that a 
reader first reads the entire header in memory, then takes actions 
according to its content (and looks up keywords by name, defaulting values 
in case of absence or declaring error if mandatory).

It should not be too heavy a burden for a reader to have a sort of cache 
for the header, even in case of a non-disk input stream like e.g. reading 
from an URL. The times of magnetic tapes are gone (although in that case 
the blocking helped ...)

It looks like that inheritance across alternate WCSs is not considered by 
the standard. Otherwise said each WCS is independent.

8.2.1 at pag, 29 says "If an alternative WCS description is specified, all 
coordinate keywords for that version must be given even if the values do 
not differ from those of the primary version"

So, if they are given and do not differ, they are repeated.
If they are't given, the rules for default apply to each WCS 
independently.

Said all that, formally it looks like that all WCSAXESa shall preceed all 
other WCS kwds (i.e. Bill's examples 1a 1b).

This might be a good practice for clarity (it would even be better for 
documentation if all WCSNAMEs are declared first), but seems not necessary 
for any sensible s/w reason (i.e. Bill's examples 3a 3b where each WCAXESa 
precedes its own WCS kwd set do not look terrible).

-- 
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)




More information about the fitsbits mailing list