Subject: Comment on draft FITS standard revision 1.2

From: Clive Page <cgp at leicester.ac.uk>
Date: Mon, 20 Apr 1998 12:30:58 +0100 (BST)

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.

---

From: sla at ucolick.borg (Steve Allen)
Date: 22 Apr 1998 00:42:11 -0700

Many thanks to the NOST Technical panel for putting this together.

Section 5.2.1

Now the minimum string length is no longer required to be 8 characters.
Presumably a null string is now a legal possibility, represented
AKEYWORD= ''
I've written regular expressions which correctly interpret this, but
does this need any special mention to distinguish it from a broken
attempt to encode an apostrophe?

Consider pathological cases akin to
AKEYWORD= ''    / isn't this funny?  'concatenated'' ''comments'

5.2.4 and 5.2.5 vis a vis 8.1.5

I am aware of the existing cases of FITS ASCII tables where there are
spaces embedded within integers and floating point numbers.  Does the
new prohibition against spaces within real and floating point values
imply that there are no known cases of FITS headers with embedded
spaces in the keyword values?

I know that I have constructed such things while exercising FITS
reading code, so it seems dangerous to proclaim that they need
not be handled anymore.

5.4.2.2

This is something I wish I'd caught during the wordsmithing of the Y2K
text.  The intent of the phrase
"shall be UTC for dates since 1972 and UT before" is perfectly
clear to someone who understands that the UTC epoch began
1972-01-01.  To others, however, it would be clearer if the
text were more explicit, say
"shall be UTC for dates beginning 1972-01-01 and UT before".

5.4.2.5

The definitions of DATAMAX and DATAMIN might be a little clearer if
the wording was "maximum valid physical value represented by the array"
instead of "in the array".  This would serve to emphasize that the
DATAMAX/MIN apply to the values after application of BSCALE/BZERO.
Alternatively, other language could make this equally clear.

8.3.2

TFORMn values for binary tables will all-too-soon face the need
for 64-bit integers.  The P format could be pressed into service
for this, but it would be better if the question of 64-bit integers
were addressed directly.

8.3.4

Data display of binary table data requires the FORTRAN behavior of
writing asterisks ***** when the value does not fit the field.
Is this constraint really necessary?  Can't we permit a broader
view of data than this, such as is seen in C printf?

Appendix A

I can't say thanks enough to those who worked out the BNF.  With this
it looks like Don Wells might simply write a one or two page RFC
proposing the FITS MIME types and incorporate NOST 100-1.2 by
reference.

For tidiness, page 53-54 splits the definition of decimal_number
across the page.  These definitions would be best not broken.

Appendix E, point 34

there's a typo BIMTABLE instead of BINTABLE
-- 
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.borg     Voice: +1 408 459 3046     FAX (don't): +1 408 454 9863
WWW: http://www.ucolick.borg/~sla               PGP public keys:  see WWW
Junk mail is irrelevant -- my return address has been assimilated.

---

From: Don Wells <dwells at nrao.edu>
Date: Wed, 22 Apr 1998 09:53:58 -0400 (EDT)

Steve Allen writes:
 > .. Appendix A
 > reference..

I do intend ask IAU-FWG to approve filing for MIME [Multipurpose
Internet Mail Extensions] content-type codes after NOST 100-1.2 is
approved by NOST and by the FITS committees.  As you suggest, the
application will probably consist of a formal Internet RFC
[Request-For-Comments], which will reference our standards document
and summarize it tersely.  This approach will be required because FITS
should get top-level codes (probably 'image/fits',
'application/fits-image', 'application/fits-table' and
'application/fits-group'), and IANA [Internet Assigned Numbers
Authority] requires a published RFC to get such codes assigned.

-Don Wells [Chair, IAU-FWG]
-- 
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
		    http://www.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA