[fitsbits] Five FITS Proposals

[Peter Weilbacher]

Dear Bill,

On Wed, 23 Oct 2013, William Pence wrote:

> During the recent FITS Birds-of-a-Feather session at the ADASS meeting
> on Sept 30th, there was some discussion about the shortcomings of the
> current FITS format.  This discussion has motivated me to consider what
> relatively simple changes could be made to FITS to address some of the
> most commonly heard complaints.  After some discussions with a few of my
> colleagues, I've drafted 5 specific proposals that should be fairly
> simple to implement:

I did attend the BoF and also read as much of the Thomas et al. poster
as I could. So I very much welcome your attempt to guide FITS into a
direction that could address some of the issues raised. But since the
criticism of FITS put forward at ADASS was more about "data model" and
things that in a sense are a layer on top of FITS, like the WCS, I am
skeptical in which sense these current proposals help. So was the
audience -- I recall that about 2/3 to 3/4 of the attendents voted to
leave FITS as it is and start something new.

> 1.  Allow longer keyword names

I agree that this would be nice, but only if this would make an existing
large collection of FITS files valid. Since you do not include the
HIERARCH convention in this proposal by disallowing keywords with
spaces, I don't think this change would be helpful.

> 2.  Allow arbitrarily long character string keyword values

Never having used the CONTINUE convention (to my knowledge) I wonder if
there have been so many bad experiences with re-ordered FITS headers
that this new proposal is actually needed?

> 3.  Allow additional characters in keyword names

I don't see where this is coming from, although I would like it, if the
dot was allowed (no strong reason, though). To me it doesn't make much
sense to allow lower case characters, if they are no significant. This
would also have the danger that people might start writing e.g. cd12
instead of CD12 and older FITS viewers would fail to find the WCS.
It's already difficult enough because so many people ignore
case-sensitivity of units in FITS headers, I don't think we want to have
as much confusion about keywords.

> 4.  Introduce a new FITS version keyword

This was one of the Thomas et al. suggestions at the BoF, but I didn't
really get the point. How does it help older FITS readers if a FITSVERS
keyword is there which they don't understand?

> 5.  Define a convention for preallocating space for keywords in FITS
> headers for later use

Since I have to deal regularly with FITS files of sizes of 10 GB and
more I like this idea. However, I stumbled over
   The first non-blank keyword that preceeds the END keyword
   marks the 'effective' end of the header.
Should this not be "The last non-blank ..."?
But again, I am confused to how this would help if someone uses an older
FITS handler which would then like remove that space again.

Just my 2 cents.
   Peter.
-- 
Dr. Peter Weilbacher                http://www.aip.de/People/PWeilbacher
Phone +49 331 74 99-667                       encryption key ID 7D6B4AA0
------------------------------------------------------------------------
Leibniz-Institut für Astrophysik Potsdam (AIP)
An der Sternwarte 16, D-14482 Potsdam

Vorstand: Prof. Dr. Matthias Steinmetz, Dr. Ulrich Müller
Stiftung bürgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026