[fitsbits] The CONTINUE and HIERARCH Conventions Public Comment Periods
William Pence
pence at milkyway.gsfc.nasa.gov
Mon Sep 10 12:45:04 EDT 2007
Robert Hanisch wrote:
> The description of the HIERARCH convention is inconsistent, I think,
> regarding the length of the component tokens.
>
> At the top of p. 2 it says
>
> "Under the ESO implementation of this convention, each token string which
> precede[s] the equals sign conforms to the requirements for a FITS
> keyword..."
>
> But in Section 2, this rule is abandoned and the same scheme is used for
> defining long and non-conforming keyword names. So, as written it is not
> really clear whether it is the ESO implementation that is being discussed,
> or the more general thing. That is, would the following conform to the
> convention?
>
> HIERARCH HST-ADVANCED-CAMERA APERTURE$Setting = 2
No, this does not conform this convention. The 2 tokens
("HST-ADVANCED-CAMERA" and "APERTURE$Setting") are not legal FITS
keyword names, so this does not conform to the ESO use of the convention
(although ESO bends the rules slightly, and does allow tokens longer
than 8 characters). The more general HIERARCH convention that is
described in the last half of the document disallows spaces in the
"effective keyword name", so this example does not conform to that. If
you replaced the space between the 2 tokens with an underscore, then it
would conform to the more general convention:
HIERARCH HST-ADVANCED-CAMERA_APERTURE$Setting = 2
> Finally, on p. 3 it says "This convention should not be used if the
> effective keyword name can be represented as a standard FITS keyword...". I
> think it can be argued that one can always find a standard FITS keyword
> representation, as has been done 1000s of times in FITS headers.
The statement you quote is intended to disallow usage like this:
HIERARCH USERNAME = "John"
In this case, "USERNAME" is a legal FITS keyword name, so there is no
need to use the more complicated HIERARCH convention.
> I believe I share some responsibility for the invention of HIERARCH (I
> think I first suggested it at a FITS WCS meeting in Charlottesville, ca.
> 1989). I have regretted it at various times ever since.
I initially shared your dislike of the HIERARCH convention, but have
changed my mind after seeing how well it has worked in the ESO FITS
files. If you look at the sample FITS header listing from ESO given at
http://fits.gsfc.nasa.gov/registry/hierarch_keyword.html (the fors.txt
link) there are hundreds of keywords that use this convention in each
file. It would be difficult to come up with clear and informative
8-character names for this many keywords. I think ESO has done a pretty
good job of defining a self consistent set of hierarchical keyword names
for all its dozens of telescope and instrument data systems. I agree
however that it probably would not make sense to use the HIERARCH
convention for just a couple keywords in a file.
I don't particularly like the more generalized use of the HIERARCH
convention to create keyword names that are longer than 8 characters or
contain non-standard characters (even though I added support for this in
the CFITSIO library). If we really want to extend FITS to allow longer
keyword names, then I think a much simpler way to do this is to just
allow free-format keyword records in which the "=" can appear anywhere
after byte 9 of the record, such as:
MY_LONG_KEYWORD = 17 / comment string
Note that this keyword is perfectly legal under the current FITS
Standard: existing FITS readers should interpret this as a
commentary-type keyword, with the 8-character name "MY_LONG_" and the
rest of the record treated as a comment string.
Bill
--
____________________________________________________________________
Dr. William Pence pence at milkyway.gsfc.nasa.gov
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)
More information about the fitsbits
mailing list