Subject: Having FITS

From: [email-masked] (John Ball)
Date: Fri, 27 Oct 89 15:19:40 EDT

NEROC Haystack Observatory

                     Westford, Massachusetts  01886  USA

                                 Memorandum

To:            Distribution 

From:          John Ball                               1989 October 27

Subject:       Having FITS 

        At Haystack, we now have the following three programs to write
FITS tapes from Haystack spectral data:

               1)  FITS reads stashes and writes canonical FITS
        tapes as defined in E.W. Greisen and R.H. Harten, "An
        Extension of FITS for Groups of Small Arrays of Data,"
        Astronomy & Astrophysics Supplement Series 44:371 (June
        1981).  So far as I know, there is no program anywhere
        that can read this FITS format; this FITS program is
        probably useless.
 
               2)  FITS2 reads stashes and writes CLASSy FITS
        tapes.  CLASS is a radio-astronomical data-reduction
        program produced in France by the Grenoble group,
        released to the public, and being used by Karl Menten and
        John Szczepanski (and others?) at CfA.  CLASS now runs
        only on VAXes, but a version for Unix machines is being
        discussed.

               3)  FITS3 reads any of 11 spectral files (including
        #RTSLD, #BUSLD, #PRTDn) and writes CLASSy FITS tapes.

        FITS for single-dish data should be defined as a file format,
not a tape format.  We can reasonably expect that by the time the
format is implemented, most observatories and most users will be
transferring data over electronic links from one computer to
another.  A tape format might be just a bit-for-bit copy of the
disk format or maybe an observatory-specific format for archiving. 
There is no particular reason why an observatory should record or
archive in FITS format, although this should be possible.  The
point is to make FITS available to investigators over an electronic
network and with luggable media.

        I imagine an investigator at his office anywhere calling up
scans into his favorite data-reduction program and reviewing them
on his screen within a few seconds after they were acquired at a
remote telescope.  Alternatively, an investigator at the telescope
should be able to send data to his own computer, run a data-
reduction program on them, view the results at the telescope, and
be sure that the data are safe on his own disk before leaving the
telescope.

        One can imagine arbitrarily complex data formats, and these
may be useful for some specialized purposes.  I urge, however, that
a simplified version of the FITS format should be permissible
within the specifications.  Allow, for example, omission of
parameters that can have default values.  Allow omission of
parameters that can be calculated from other parameters.  Example: 
galactic latitude and longitude can be calculated from RA and Dec. 
Allow omission of parameters that are just unknown.  Example: 
atmospheric attenuation.  (Do you suppose that my program to
calculate atmospheric attenuation from surface meteorology is
better than yours?)  The simplified format should contain raw
data--all the raw data; other parameters can be calculated later. 
That is called data reduction.  There is no particular reason why
the reduced data should be kept in FITS format, although this
should be possible.

        Insure that some program somewhere can read the new FITS
format.  How can those of us at observatories test our new FITS-
writing programs if nobody can read their output?  A published
standard is useless and worthless if nobody can use it.

        Make your specifications so clear and so definite that those
of us who have to read and use them, no matter how stupid or
inattentive we are, cannot misunderstand your intentions.  Make
misinterpretation difficult, if not impossible.