[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