Subject: Re: GBT use of FITS for single dish data

From: [email-masked] (Bob Garwood)
Date: Thu, 16 Mar 1995 11:17:19 +0500

Harvey has asked that his response to Ray's comments be forwarded to the
dish fits exploder.

----- Begin Included Message -----

---

From: [email-masked] (Barry M. Schlesinger)
Date: 22 Mar 1995 11:52 EDT

In article <[email-masked]>, [email-masked] (Bob Garwood) writes...
>From [email-masked]  Thu Mar 16 09:22:02 1995
>Subject: Re: GBT use of FITS for single dish data

			[...]

>Ray--
			[...]
>It
>seems to me that in many (most?) cases, the actual dimensions along all n axes
>don't need to be contained in the header; only n-1.  Given the fixed size of
>each instance, the size of the file alone determines the dimension along the
>last axis.  Or alternatively one can simply read until the final END statment
>is encountered or an EOF.
> 
>Does this make sense?  It seems to me that either a reader could purposefully
>ignore the supposed value in the header for the number of rows in a table or
>in a map, or the naxisn[naxes] could be set = * in the header to tell a reader
>to read exhaustively, not up to a fixed index.  This applies to tape more than
>to a disk file; if the size of a file is known, the naxisn value along the last
>axis can be figured out even if it is not in the header.   We've grown too
>accustomed to having the FITS header spell everything out for us; remember the
>old days of writing programs that read in a number of data points that _wasn't_
>known ahead of time?
> 
>regards, 
> 
>Harvey Liszt
> 

The problem with this proposal is that it violates a requirement of 
the Generalized Extensions paper:

"-A program scanning a tape should be able to locate the begginning of 
any extension and should be able to skip over the extension, i. e., to 
find the start of the next one.  This requirement implies that the 
extension header must specify in some consistent and standardized 
manner the total number of data bits which are associated with it."  

The original motivation for this requirement was to permit software to 
skip extensions in a FITS file that it did not know how to handle, by 
reading the name and size from the header.  The name would identify 
the extension type as one the software could not handle and the size 
would allow the software to skip to the next extension.  So, in the 
first instance, readers that cannot read BINTABLE should be able to 
skip to the next extension.

This requirement also makes it possible to construct utility programs 
that dump all the headers in a FITS file without reading the data.
After reading one header, they use the information in it to skip to
the next. Such software is a very useful tool for examining newly
received files. 

					Barry Schlesinger
					FITS Support Office