From dishfits-request@fits.CX.NRAO.EDU Tue Feb 13 15:30:41 1990
Received: from NRAO.EDU (cv3.cv.nrao.EDU) by fits.cx.nrao.edu (4.0/SMI-DDN)
	id AA20054; Tue, 13 Feb 90 15:30:39 EST
Received: from fits.cx.nrao.edu by NRAO.EDU (4.0/DCW-2o    )
	id AA10900; Tue, 13 Feb 90 15:27:46 EST
Received: by fits.cx.nrao.edu (4.0/SMI-DDN)
	id AA20044; Tue, 13 Feb 90 15:18:53 EST
Return-Path: <@CUNYVM.CUNY.EDU:FRANCOIS@DGAESO51.BITNET>
Message-Id: <9002132018.AA20038@fits.cx.nrao.edu>
Status: RO
From: FRANCOIS%DGAESO51.BITNET@CUNYVM.CUNY.EDU
Sender: dishfits-request@fits.CX.NRAO.EDU
To: DISHFITS@FITS.CX.NRAO.EDU
Subject: YAF (Yet Another Fits...)
Date: 13 FEB 90 20:10-ECT

Date: 13-FEB-1990 20:10:35.55
From: Francois Ochsenbein (089)32006-346 FRANCOIS AT DGAESO51
To:   ESOMC1::0::"dishfits@fits.CX.NRAO.EDU" ! SENT TO @FITS
Subj: YAF (Yet Another Fits...)
Don,

I would like to raise three points concerning FITS:

1) Regarding the HIERARCH controversy (which can also be seen as a facility
   to extend the keyword to more than 8 bytes): the main problem with the
   HKBEGIN / HKEND scheme proposed by Bob Hanish is, as mentioned previously
   by Preben Grosbol, that this scheme will lead to misinterpretations by
   existing FITS readers, when the keyword which is between the HKBEGIN /
   HKEND supersedes a previous definition; the HIERARCH notation takes more
   space on the line, and therefore reduces the place left for comments ---
   but a 32-byte keyword normally requires less explanations than a
   cryptic name.

   An intermediate solution could be the usage of Bob's HKBEGIN/HKEND,
   but with an indentation of the keywords between HKBEGIN and HKEND,
   such that old FITS readers just take these as comments; the indentation
   could be a function of the depth to visualize better the structures,
   or a fixed value of 8 blanks. Example:

HKBEGIN 'GENERAL'
        STATION = 'Station-Name'
        FREQ    =       11.5E9
HKEND   'GENERAL'

2) The 3-D tables will be extremely useful for the exchange of data
   extracted from / to be inserted into relational data-bases.
   Along this line, I have some questions, propositions and comments:
   a) availability of 8-bit integers (in the range -128/+127);
      this dataytpe could be named B (for byte)
   b) some further descriptions about the table would be required:
      which columns or combinations of columns should be unique
      or indexed, ... a keyword INDEX or UINDEX could be used.
   c) the TFORMxxx keyword is a bit misleading to describe datatypes ---
      and formats for the edition of a 3D-table would be useful anyway.
      Would it be relevant to change TFORM to e.g. TDATA and keep the
      TFORM keyword to provide a format ?
   d) Will however the TSCAL / TZERO be allowed in the 3D-table ?
   e) will be the byte boundary be the only alignment requirement,
      for any data-type ?

3) FITS files over the network:
   which is desirable anyway. There is no problem with the header which is
   in ASCII format; the binary part could be transformed to ASCII using e.g.
   the Unix uuencode / uudecode, or some other procedure; a standard
   compression algorithm may then be applied to reduce the size. I tried on
   a 800x800 image (8 bits dynamic range) and the size is roughly divided fy
   4, giving a 16-K file for such an image. A transmission over the network
   of such files would take a fraction of a minute.