Subject: Prototype implementation

From: "FORVEILL@FRGAG51" <[email-masked]>
Date: Tue, 28 Nov 89 09:53:25 EDT

Date sent:  28-NOV-1989 13:26:54.63
To:   DISHFITS@NRAO
 
        Dear colleagues

Althought I have been silent on this list since the Green Bank meeting, I
have not been inactive, and I now have a working prototype implementation of
our agreement. The present version has limited functionalities, in that the
writer only writes as table columns the CDELTi (which as discussed a the meeting
can be used to code position offsets) and (of course) the data matrix. This
is already sufficient to store spectra obtained at random offsets around
a reference position. The reader is a bit more general and supports all
matrix description keywords (CRPIXi, CRVALi, CROTAi, MAXISi, AXTYPi).
Extensions are of course trivial, and I may add a few other important keywords
one day. I will now probably defer any major work till I receive sample files
from Harvey Lizst for a cross check. In the mean time, I would like to
discuss my experience with the new extension, make a few comments on the
draft agreement and ask for opinions on a few questions.
 
My dominant feeling is that the design is sound and can be implemented
reasonably easily. Program complexity is obviously increased relative
to the basic FITS agreement, but the large efficiency gain is worth
the additionnal effort.
 
I would like EXTNAME to become a required keyword for 3D tables. 3D tables
are general enough that I would like to check, before I even attempt to, that
I am not trying to decode a Clean Component table, or ROSAT photon lists.
 
We should probably require MAXIS to be in the extension header and not in
a column. If some people really want to store matrix with variable number
of axes they can define extra dummy axes. That would be poor style
anyway. This limitation eases implementation, since axis work space can
then be allocated while reading the header (or checked for overflow in
static implementations).
 
My impression is that the TUNITi keywords are redundant with the requirement
that all quantities in a FITS file be in SI units. There is the risk that they
encourage the use of non standard units, and I would therefore advocate their
exclusion from the 3D table proposal.
 
The 3D draft specifically requests that GCOUNT=1. One could imagine allowing
larger values of GCOUNT, thus providing an additional hierarchy in the file.
Should that be allowed, explicitely forbidden, or reserved for future use?

Some comments on the message of Paul Harrison
1) I have no objections to AZIM and ELEV. Note however that these keywords
don't refer to matrix axes. They are basically atmospheric (+pointing)
parameters and I see no reason why they would be projected. Horizontal
coordinates are of course perfectly legal for the matrix, but they would
then be stored as CTYPEi (with a value of 'AZIM-GLS', or anything like that).
3) I strongly oppose using CRVALn arrays to store non regular coordinates.
CRVALi has a well defined meaning in the basic FITS paper and this is NOT
an array. Althought the proposed modification only affects 3D tables, it
breaks the correspondence principle and general unpackers become unpractical.

        Thierry