[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