A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

[fitsbits] Proposed Changes to the FITS Standard



 
 
Thread Tools Display Modes
  #1  
Old July 24th 07, 07:21 PM posted to sci.astro.fits
Rob Seaman
external usenet poster
 
Posts: 49
Default [fitsbits] Proposed Changes to the FITS Standard

Please post any comments, suggestions, or concerns regarding these
proposals (or any other suggestions for improving the Standard
document)


Good job. Time well spent. Thanks to all involved.

Comments indexed to the summary:

1.4) Extensions ARE special records from the point of view of
classic FITS readers. Rather than deprecating or attempting to ban
them, perhaps just explicitly state that new uses for special records
require IAUFWG approval. (But see 1.10 below.)

1.5) Unenforceable in the absence of some explicit mechanism tagged
to the DATE keyword (for instance). On the other hand, such a
mechanism would be equivalent to explicitly versioning each file.
This would be a change to the basic philosophy of FITS. I think of
opening old Word files with new editions of MS Office - or worse -
trying to do the reverse.

1.6) Harmless, but also unenforceable. Not just an attempted
constraint on software, but also on humans editing headers manually
using IRAF hedit, for instance.

1.7) No, but there are many headers that unintentionally repeat
keywords. They should not therefore be rendered unconforming FITS.

1.9) Few users will choose 64 bits when 16 will do. Those that do
may well have a good reason.

1.10) This is a requirement placed by the IAU, not FITS per se.
Might such policies better be concentrated in a common section? On
the other hand, it is eminently practical to manipulate unknown but
conforming extensions. In particular, software we write today can
skip and list and otherwise manhandle conforming extensions from
tomorrow.

3.1) Italicizing these words may be distracting. Must it be done?
I should not recommend it. Shall it be optional?

In general, as with the previous comment about the EXTEND keyword, we
should be careful what we attempt to require regarding new data since
it may place unfunded mandates on old software. Deprecation of a
feature is not equivalent to requiring its converse.

A couple of other general comments:

Any chance of blessing checksums on this go-around? Then we could
fret about using "one's-complement" versus "one's complement", too.

There is a very real possibility that UTC will be turned into
something other than a flavor of Universal Time, i.e., other than an
approximation to Greenwich Mean Time. Perhaps we should consider how
best to deal with such a situation. A generic "UT"? Use raw UT1?
Define a UTA (Astronomical) retaining IAU mediated leap seconds?
This is a broader issue than FITS, but we would have to start somewhere.

Rob


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[fitsbits] Proposed Changes to the FITS Standard William Pence FITS 2 July 24th 07 04:57 AM
FITS long integer support (was [fitsbits] ADASS FITS BoF onSunday) Eric Greisen FITS 10 October 26th 04 08:14 AM
FITS long integer support (was [fitsbits] ADASS FITS BoFon Sunday) William Pence FITS 6 October 22nd 04 08:23 PM
[fitsbits] proposed FITS MIME types Internet Draft Steve Allen FITS 0 October 1st 03 05:49 AM


All times are GMT +1. The time now is 09:20 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.