View Single Post
  #1  
Old September 10th 07, 06:26 PM posted to sci.astro.fits
Rob Seaman
external usenet poster
 
Posts: 49
Default [fitsbits] The CONTINUE and HIERARCH Conventions Public CommentPeriods

If the registry serves to bring order to chaos, it will be a net
positive. If it serves, rather, to advertise conventions willy-
nilly, it may be a net negative. I'm really nervous at the thought
of random naive users including HIERARCH keywords in their
documents. Bob's examples and Bill's comments demonstrate that even
expert FITS users may differ on the legality of HIERARCH usage.

On Sep 10, 2007, at 9:45 AM, William Pence wrote:

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 [...]
there are hundreds of keywords that use this convention in each file.


One has always wondered at the project requirements that lead to
including hundreds of keywords in a FITS file.

I agree however that it probably would not make sense to use the
HIERARCH
convention for just a couple keywords in a file.


Can we hope to successfully legislate this?

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).


Me neither!

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


Bleh! No, no, no. Talk about needing to version FITS...

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.


I don't think we've ever tested this in anger. A lot of FITS
applications likely still assume that the only commentary keywords
are COMMENT, HISTORY and BLANK. We just had an issue with a
technically legal BLANK keyword throwing an error due to an
extraneous equals sign in column nine.

If we want to address the issue of including elaborate header
metadata in FITS, I suspect I wouldn't be alone in preferring a
bintable based solution, perhaps located as the last HDU at the end
of each file (where lots of folks wanted the header in the first
place). This, too, is already perfectly legal FITS.

Rob