Comment on draft FITS standard revision 1.2

[Clive Page]

The FITS Technical Panel is to be congratulated on drafting a new version
of the Standard.  I have, however, a few suggestions for clarifications, 
and one more substantive suggestion at the end.


1. Section 5.3 Units - how to specify physical units in headers?

This section implies that FITS header keywords may have physical units,
but does not give any indication of how this is to be done.  This issue
has been debated a number of times, and the pragmatic solution agreed at
the last HEADCC meeting is now implemented in FITSIO: the units may be put
in square brackets at the start of the comment field of any header line.
Since this convention is now beginning to be used widely, I think it ought
to be mentioned somewhere.  This could be a new section in Appendix B, with
suitable references from sections 5.1.2.3 and 5.3.


2. Section 5.3 Units - do columns have to use degrees not radians?

When it says "degrees are the required units for celestial coordinate
systems" it is not clear to me whether this applies only to header keywords
such as those using the WCS, or is intended to be more general than that,
e.g. applying also to columns in tables.   I note that the sections on
units in ASCII and binary tables (8.1.2 and 8.3.2) refer to section 5.3.

If the more general interpretation is implied, I would like to disagree
with the implication that degrees and not radians are to required for
angular quantities in FITS tables.  FITS headers were designed to be 
legible to humans, and in this case degrees may well be a better choice of
unit, but the same does apply to columns in tables especially binary
tables, which always have to be processed by machines.  In my opinion
radians are the better choice in such cases: the radian is the SI unit of
angle, and it is also the unit used for trig functions in languages such as
C and Fortran.   Tables containing degrees nearly always have to be
converted to radians before use: this uses unnecessary cpu cycles, and may
lose accuracy.


3. Section 8.3.2, table 8.6.

Iw should be Iw.m to be consistent with section 8.3.4.


4. Section 8.3.2, table 8.6.

The specification "integers only" for B/O/Z formats does not make it clear
whether these formats may also be used for bit (X) and byte (B) data types.
Most reasonable interpretations would assume so, but this would be better
made explicit.

I think it would also be useful to have a note in the table caption that
the ".m" and "Ee" sections of each format are optional.  This is specified
in detail in section 8.3.4 but you have to read the dense prose rather
carefully to see that this is so.


5. Section 8.3.3.1 - Logical

When it says "A zero byte indicates an invalid value" it may not be
absolutely clear whether this means hexadecimal zero or the character "0",
although I think that the former is intended. The qualifier "hexadecimal"
is used in similar contexts elsewhere, and it would be clearer to see it
used here.


6. Section 8.3.4 Data Display - Integer data

I think it should explicitly say that integer, bit, and byte data may use
format codes Iw.m etc.

This section also leaves unclear what is required for complex data (types C
and M), though I assume that a single instance of any of the formats usable
for real data will suffice.

7. A Suggestion for support for sexagesimal output

FITS tables, especially binary tables, are often used to store
lists or catalogues of celestial objects.  Large collections of them, such
as the CDS, have FITS tables as a principal export format.
Such tables invariably
include columns of Right Ascension and Declination. Astronomers seem
firmly attached to the habit, established in Babylonian times, of showing
such coordinates in sexagesimal notation: hours-minutes-seconds for RA,
and degrees-arcminutes-arcseconds for DEC.  Unfortunately there is no way
of specifying that a sexagesimal display format should be used when RA or DEC
values are present in FITS tables.  

I note, however, that the TDISP indexed keyword merely specifies the
"recommended" display format for each column, so the introduction of
additional TDISP format codes should not cause problems with existing
software, which could simply ignore them (as do some current systems when
faced with EN or ES formats). I would like to suggest  that there should
be two additional TDISP format codes, to be added to those in table 8.6.,
namely:

  USw.d   Unsigned sexagesimal: displays field as hh:mm:ss.s...
           
  SSw.d   Signed sexagesimal:   displays field as Sdd:mm:ss.s... 
          where S is the sign "+" or "-".

In both cases the "w" parameter specifies the overall width, "d" specifies
the number of digits after the decimal point in the seconds/arcseconds field.  
For these codes to be valid the TUNIT field would have to specify the units
within the FITS column which should be either degrees or radians, and any
display program would have to perform the appropriate, if rather trivial,
calculations to convert them to hours or degrees and sexagesimal fractions.


-- 
Clive Page,
Dept of Physics & Astronomy,        
University of Leicester.