From: [email-masked]
Date: Wed, 25 Oct 89 10:43:42 EDT

Subject: Comments on a FITS Standard for Spectral Line Data
>From Robert W. Wilson, AT&T Bell Laboratories

Dear Single Dish FITS Conference Participants:

The most important thing, of course, is to have A STANDARD.  I will
almost certainly write a reader and writer for what ever new standard
emerges.

The one thing that I think must be changed from present FITS practice
is that multiple spectra should be allowed in a single file.  This
could be done as easily as simply writing multiple spectra one after
the other in a file.  It would take a minimum of cpu time to read the
header of an unwanted spectrum and calculate how many (2880 byte)
blocks to skip.  There would be no reason to announce how many spectra
are comming; the EOF would tell you when you are done.  This would
make exabyte tapes and disk files usable and all other efficiency
considerations would be of little consequence for the amount of data
that I foresee transporting in and out of Bell Labs with FITS.  (Tape
records blocked to a multiple [10?] of 2880 bytes would then be
desirable for IBM tapes.)

The other thing which is badly needed is a set of standard keywords.  I
think that there should be a required core set which would be adequate
for reduced data.  An extension set should be strongly encouraged if
the information is available and applicable.  As an example of what I
mean by this is in the data header which we have been using at the Bell
Labs 7-meter antenna.  A number of the parameters correspond to the
lock system which was used at the 36-foot in the early 1970's even
though our lock loop is different.  The only loss in keeping the old
definitions is a few arithmetic operations per spectrum in the
observing program (and occasionally puzzling over the code).  There was
considerable saving during the transition period when we had both kinds
of data.

I hope that I will not have to make use of very many telescope
dependent parameters when reading data from other observatories.
Observatories with idiosyncratic instruments should reduce their export
data so that it can be described in a normal way rather than expecting
all users to  add special code to handle their special case.  I include
in this category AOS spectrometers with non-linear frequency sampling.
If the original sampling is adequate, resampling on a regular grid
should not change the data (although some of the original high
frequency noise may be removed).  Of course transfer using FITS will
need to handle the raw data in whatever from it is produced for
internal transfer and transfer to frequent observers.

I like Bob Hanish's proposal for hierarchical keywords better than Don
Wells' proposal of stacking them up on the line with the most
particular word first.  I worry that this extensibility will be
abused.

I like the idea of 3-D binary tables for efficient transfer of large
amounts of data, but don't completely understand them yet.  If I am
forced to implement them, I might keep our raw data in that format,
since, except for the initial header the data file is already a binary
table.

As a final comment, I think that observers should be able to refer to
all of the data taken at the same time by a common observation number.
I am also used to integer 'scan' numbers and don't have a good proposal
for the case of multiple feeds/receivers/backends.  For exchange with
foreign systems, each spectrum should be a separate FITS entity with
some form of observation number in it.  (Actually this would argue
against keeping multiple backend raw data in FITS format.)

Bob Wilson
[email-masked]
201-888-7120