Subject: Single-dish FITS

From: Michael Olberg <[email-masked]>
Date: Thu, 26 Oct 89 14:04:35 -0100

I would like to make a last minute contribution on two issues before the 
workshop next week.

a) Assuming that a new FITS format would impliment a hierarchy of keywords
covering GENERAL, SNGLDISH GENERAL and finally SNGLDISH WHATEVER
keywords or anything equivalent to that, could we produce FITS reading 
programs which could learn about anything that had not been general enough 
to be implemented right from the start? I am thinking of something 
like this:

Allow definition of FITS keywords within FITS:

0........1.........2.........3.........4..................................8
123456789012345678901234567890123456789012345.........................67890

DEFINE  = 'SEST-15M'           / start definition of SEST specific keywords
KEYWORD1= 'F10.1   '           / define KEYWORD1 and format how to read it
KEYWORD2= 'L10     '           / example of a keyword holding a logical ... 
KEYWORD3= 'A10     '           / ... and character information
ENDDEF                         / end keyword definition section

This definition section could be written out as a first block on a tape
integrated in a standard FITS header and should be thoroughly commented. 
Now, if any of the following headers contained

TELESCOP= 'SEST-15M'          / telescope used

which is one of the allowed keywords in FITS, only then would the program 
be prepared within the same header to understand and correctly read any 
lines like

SNGLDISH SEST-15M  KEYWORD1=       12.3
SNGLDISH SEST-15M  KEYWORD2=          T
SNGLDISH SEST-15M  KEYWORD3= ' a string '

If the TELESCOP= line had not been present, the SNGLDISH SEST-15M lines 
should be ignored. This would allow slightly different implementation of
identical keywords at different telescopes, i.e. everybody may use very 
obvious keywords without knowing how exactly they are used somewhere else.

b) Along the lines of adopting IEEE floating point formats for binary
encoding of data, which I very much agree with, let's also adopt a 
standard for an extended 8 bit character set. Maybe we could even 
agree on how to encode greek, japanese etc. characters. If we want others
to accept a standard proposed by us, we should be open minded about 
standards that other commitees have already come up with.