Revised FITS

[Francois Ochsenbein]

Let me first congratulate the useful job of the Revised FITS Standard NOST!
The explicitation of the F77 conventions is especially useful, since I have
the impression that this knowledge is fading out... For instance, the
explicit conventions of the F77 format in section 8.1.5 is useful,
since I've frequently heard colleagues claiming that an interpretation, 
with a F5.3 format, of the strings " 1230" and " 123 " lead to the same
number 1.23 ... and this is not true (the first form gives 1.23, 
the second 0.123)

I've gathered several comments I wish to submit for the final version:

Section 5.2 (keyword values)
   I feel the definitions and usage of the "fixed format" are 
   not quite straightforward to understand:
   - "fixed format" in reality only concerns integer and logical data,
     since no mandatory keyword exists for or complex number
     (and for character data, I see only the XTENSION keyword as mandatory)
   - The note in section 5.2.4 "The full precision of 64-bit values 
     cannot be expressed as a single value using the fixed format"
     is not true, since at least all values which can be expressed 
     without the exponential part are fully expressed in 20 bytes; a more 
     correct note would be "The full precision of 64-bit values cannot 
     be expressed over the whole range of values using the fixed format"
   - I would suggest to add a reminder about the fixed format in section
     5.4.1. e.g. "Values expressed by the mandatory keywords must
     be written in fixed format, i.e. right-aligned in bytes 11-30
     for numeric values."

Section 5.2.1 (Character String)
    It is not explicitely stated that an empty string is allowed, normally
    made of two consecutive quotes anywhere between columns 11 and 80. Or
    should the empty string be written as only spaces (i.e. no quote at
    all)?
    I think Steve Allen is wrong in his example
    AKEYWORD= ''    / isn't this funny?  'concatenated'' ''comments'
    AKEYWORD is without doubt an empty string, a single apostrophe is
    written
    AKEYWORD= ''''  / This is a single apostrophe
    A correct wording could be:
    "A character string value is expressed as an opening quote, followed
    by the contents of the string made of ascii text, followed by a
    closing quote; the quotes within the string are doubled, e.g.
    O'HARA = 'O''HARA', or a single apostrophe is written ''''"

Section 5.3 (Units)
    As was already expressed by Cleve Page, I feel it is a very bad
    statement to require the usage of degrees for celestial coordinates.
    If this can be understood for main header keywords (e.g. related to
    WCS), there are dedicated TUNITx keywords to specify the units used in
    columns of a table -- would then a specification of anything different
    from "deg" in a TUNITx keyword describing a column of a table
    containing celestial coordinates be illegal ???

Section 5.4.2.2 (OBJECT)
    I would like to support Don's recommendation about the usage of the
    OBJECT keyword: it has been so frustrating in the past not to be able
    to use the contents of this keyword to generate meaningful lists of
    observed targets simply because the writing software imposed a limit
    (16 bytes in the applications I've used) on the size of strings... 
    Couldn't such a recommendation of at least 32 bytes (or 36) be added
    for this specific keyword ? 

XTENSION values (sections 8.1, 8.2)
    The value field includes a trailing blank for 'TABLE ' and 'IMAGE ' .
    Is this blank required ? The minimum size of 8 bytes having been
    removed, this trailing blank looks now spurious, and is not
    required according to section 5.2.1

TTYPEn values (Sections 8.1.2, 8.3.2)
    I can't see any valuable reason why .. "string comparisons with
    the values of TTYPEn keywords should not be case sensitive".
    Is it because it is wished that the contents of TTYPEn can be used as
    a Fortran variable ? There are so many astronomical parameters for
    which the case is really meaningfull (think e.g. of phometric indexes
    of UBV system versus uvby ...)

Now about ASCII tables which are used here a lot (about 5,000 tables
    exist at CDS which can be automatically transformed into FITS ASCII
    tables, either with the "tofits" program, or by simply adding the
    ".fit" suffix to the file names in our FTP server).

    Why not binary tables ?

    The basic problem is that data distributed from CDS and other
    astronomical data centers correspond to VALIDATED data, i.e. data
    which are frequently printed in refereed journals. We must therefore
    enforce that the values contained in the FITS columns are identical to
    the published ones -- but in the binary table the display format
    (TDISPx) isn't even required ! Moreover, the display in sexagesimal
    format is not yet accessible, and furthermore the binary tables can't
    make a difference between "12.1" and "12.10" unless a special column
    giving e.g. the number of significant decimals is provided. FITS is
    used here to allow an easy interpratation of the tabulated data, but
    we also have to take care of not altering the data, which
    unfortunately can't be done with the binary table format... 
    I therefore stronly object the proposed "deprecation" of ascii FITS
    tables !

Just a last short comment: looking in the index about what's an 
    "indexed keyword", it turned out that "indexed, keyword" lists pages
    15,19,69, while "keyword, indexed" lists pages 9,15,69. I can't see
    anything about the subject on page 19... Or is there any subtle
    difference I missed between "indexed, keyword" or "keyword, indexed" ?

Again, thanks for those who took care of rewriting this fundamental document !
================================================================================
Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)3 88 150 755
Email: francois at simbad.u-strasbg.fr   (France)        Fax: +33-(0)3 88 150 740
================================================================================