From owner-fitsbits at tarsier.cv.nrao.edu Sun Jun 2 19:44:19 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id TAA27868; Sun, 2 Jun 1996 19:44:19 -0400 Received: from orangutan.cv.nrao.edu (pmurphy at orangutan.cv.nrao.edu [192.33.115.11]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) with SMTP id LAA14837; Fri, 31 May 1996 11:40:00 -0400 Received: by orangutan.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA15294; Fri, 31 May 1996 11:39:54 -0400 Resent-Date: 30 May 1996 16:58 EDT Resent-From: pmurphy at nrao.edu (Patrick P. Murphy) Resent-Message-Id: <9605311539.AA15294 at orangutan.cv.nrao.edu> Resent-To: fitsbits at tarsier Message-Id: <30MAY199616584453 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!bofh.dot!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!venus.sun.com!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Newsgroups: sci.astro.fits,sci.answers,news.answers From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) To: fitsbits at fits.cv.nrao.edu Subject: Sources of FITS Information Date: 30 May 1996 16:58 EDT Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Archive-name: astronomy/fits/info-sources Last-modified: 1996/04/22 -------- Sources of FITS Information Preface This material on sources of Flexible Image Transport System (FITS) information is posted and updated periodically by the FITS Support Office at the NASA Goddard Space Flight Center (GSFC). It discusses where general FITS information, including some answers to frequently asked questions, can be found, and provides sources for detailed information on FITS software and documentation. ------- FITS Support Office The FITS Support Office maintains a library of FITS information accessible from http://ssdoo.gsfc.nasa.gov/astro/fits/fits_home.html or ftp://nssdc.gsfc.nasa.gov/pub/fits/. The material available includes o "Definition of FITS," a codification of FITS for the NASA/Science Office of Standards and Technology (NOST), available in LaTeX, uncompressed PostScript, compressed PostScript and (usually) ASCII text (The ASCII text version may not be available for a short while after the announcement of a new version.) o "A User's Guide to FITS", published by the FITS Support Office, in LaTeX, and compressed and uncompressed PostScript o Revisions to version 1.0 of the "Definition of FITS" covering the specification of units that were incorporated into version 1.1 (text) o A current list of the extension type (structure) names registered with the International Astronomical Union FITS Working Group (IAUFWG) (text) o Rules for physical blocking on various media adopted by the IAUFWG (text) In the same directory, but accessible directly via http://ssdoo.gsfc.nasa.gov/astro/fits/basics_info.html is the FITS Basics and Information that used to be regularly posted to sci.astro.fits and sci.data.formats. It continues to be revised to reflect current FITS developments. It contains the following material: o An overview of FITS o A list of FITS documents o A list of software packages that support FITS, including FITS-image converters for various platforms o A list of on-line FITS resources o A description of the FITS Support Office The hypertext version provides links to many of the documents, software, and network locations listed. The text version provides information on how to obtain much of this material. There is also a hypertext version of the List of Registered Extensions. Links from the Web page and subdirectories of the ftp directory contain o Software developed by the FITS Support Office. o Error test files, primary HDUs useful for testing the ability of software designed to read FITS files to cope with files that have errors or are non-standard. These files should be downloaded in binary form. Printed copies of the material in the FITS directory can be obtained from the Coordinated Request and User Support Office (CRUSO): (Postal) Coordinated Request and User Support Office Code 633 National Space Science Data Center NASA Goddard Space Flight Center Greenbelt MD 20771 USA (Electronic mail) request at nssdca.gsfc.nasa.gov (Telephone) +1-301-286-6695 8:00 A. M. - 4:30 P.M. U. S. Eastern Time (-0500 from the last Sunday in October through the first Saturday in April; -0400 the remainder of the year) When no one is available, messages can be left on voice mail. (FAX) +1-301-286-1635 ------- National Radio Astronomy Observatory (NRAO) A FITS Archive can be found at URL http://fits.cv.nrao.edu/ or at ftp://fits.cv.nrao.edu/fits, located at NRAO. This machine supports a WAIS server named nrao-fits which has an index of all of the FITS-related text files in the archive; the file nrao-fits.src is available at think.com and at ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src. Some of the more noteworthy materials in this archive are o Drafts of proposed additions to the FITS standard and other drafts that may in the future be formally proposed o Text of any detailed proposals currently being discussed by the FITS committees o A collection of documents on World Coordinate Systems, including the current draft proposal o Conventions specific to particular projects or disciplines o Software packages for display of FITS images on Windows 3.1, Windows 95, Macintosh, and Unix/X-Windows o Other code for various environments and Usenet postings about code o Sample data and special test files designed to measure the ability of a FITS reader to handle a wide variety of FITS files o Archives of traffic on FITS-related newsgroups and exploders ------- HEASARC The NASA/Goddard High Energy Astrophysics Science Archive Research Center (HEASARC) Web server at http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html and the anonymous ftp access through ftp://heasarc.gsfc.nasa.gov/fits_info/ provide FITS material. HEASARC has developed a the FITSIO package of software routines for easily reading and writing FITS files, in FORtRAN with a C interface available, portable to a wide variety of machines. There is also the FTOOLS collection of software tools and the VERIFITS FITS conformance verifier. HEASARC software is available directly through http://heasarc.gsfc.nasa.gov/docs/heasarc/tech_res_software.html or ftp://heasarc.gsfc.nasa.gov/fits_info/software/ . The HEASARC server also provides information from the OGIP/HEASARC FITS Working Group, (HFWG) the internal legislative body on FITS-related matters within the Office of Guest Investigator Programs (OGIP) at NASA/GSFC, at http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html or ftp://heasarc.gsfc.nasa.gov/fits_info/ . The HFWG has developed a number of FITS conventions that are more specific than the requirements of the FITS standards. Proposed conventions are publicized to the FITS community as a whole, with the goal of collaborative development of a set of conventions that will be accepted throughout the community as well as within OGIP/HEASARC. ------- Direct questions about this posting to Barry M. Schlesinger Coordinator, FITS Support Office Electronic mail: fits at nssdca.gsfc.nasa.gov Telephone: +1-301-441-4205 The FITS Support Office is operated under the guidance of the NASA/GSFC Astrophysics Data Facility. From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 13 11:13:34 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA09606; Thu, 13 Jun 1996 11:13:34 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id LAA09568; Thu, 13 Jun 1996 11:05:09 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id LAA08253 for ; Thu, 13 Jun 1996 11:05:04 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA27315; Thu, 13 Jun 96 11:05:00 EDT To: fitsbits at fits.cv.nrao.edu Date: Thu, 13 Jun 1996 00:59:36 +0200 From: Christer Strandh Message-Id: <31BF4BD8.42EA at micro.se> Organization: JamtNet / MicroKonsult Path: solitaire.cv.nrao.edu!bofh.dot!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!spool.mu.edu!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!news.uoregon.edu!news.algonet.se!newsfeed.tip.net!hagbard.midnet.telia.com!newsmaster at midnet.telia.com Subject: FITS Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk If you need a Win95/NT program to read FITS try: Quantum Image 2.00.01 beta release 'Quantum Image' is a 32-bit image restoration program useful for astronomy images... Running on Windows 95/Windows NT.. Get the beta release on Quantum Image homepage! http://www.micro.se/quantimage/ Regards, Christer Strandh Per Sabelstrom CosmoNorr From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 13 17:42:30 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA15363; Thu, 13 Jun 1996 17:42:30 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id QAA14804; Thu, 13 Jun 1996 16:43:13 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id QAA10756 for ; Thu, 13 Jun 1996 16:43:06 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA13304; Thu, 13 Jun 96 16:43:03 EDT To: fitsbits at fits.cv.nrao.edu Date: 13 Jun 1996 10:21:08 +0200 From: phjj at hippo.ru.ac.za (Justin Jonas) Message-Id: <4poj1k$70q at hippo.ru.ac.za> Organization: Rhodes University, Grahamstown Path: solitaire.cv.nrao.edu!bofh.dot!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!night.primate.wisc.edu!sdd.hp.com!nntp.coast.net!howland.reston.ans.net!quagga.ru.ac.za!not-for-mail Subject: SAOimage Newsgroups: sci.astro,sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Where is the latest version of SAOimage available? I would like to compile it on Solaris and Linux targets. Thanks Justin Jonas, Radio Astronomy Group, Dept Physics & Electronics, Rhodes University, South Africa From owner-fitsbits at tarsier.cv.nrao.edu Mon Jun 17 15:26:15 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA14335; Mon, 17 Jun 1996 15:26:15 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id UAA26010; Fri, 14 Jun 1996 20:53:00 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id UAA22534 for ; Fri, 14 Jun 1996 20:52:55 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA14991; Fri, 14 Jun 96 20:52:51 EDT To: fitsbits at fits.cv.nrao.edu Date: Thu, 13 Jun 1996 18:00:05 GMT From: Matt Phelps Message-Id: <31C05725.2E62 at cfa.harvard.edu> Organization: Harvard - Smithsonian Center for Astrophysics Path: solitaire.cv.nrao.edu!bofh.dot!hearst.acc.Virginia.EDU!news-server.ncren.net!interpath!news.sprintlink.net!news-fw-12.sprintlink.net!news.sprintlink.net!news-fw-6.sprintlink.net!news1.channel1.com!wizard.pn.com!news-in.tiac.net!canopus.hbs.edu!oitnews.harvard.edu!cfanews!news References: <4poj1k$70q at hippo.ru.ac.za> Subject: Re: SAOimage Newsgroups: sci.astro,sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Justin Jonas wrote: > > Where is the latest version of SAOimage available? I would like to > compile it on Solaris and Linux targets. > Thanks > Justin Jonas, Radio Astronomy Group, Dept Physics & Electronics, > Rhodes University, South Africa Check out the Telescope Data Center home page at: http://tdc-www.harvard.edu/TDC.html There is a pointer to info on SAOimage there. -- Matt Phelps System Administrator Harvard - Smithsonian Center for Astrophysics mphelps at cfa.harvard.edu http://cfa-www.harvard.edu From owner-fitsbits at tarsier.cv.nrao.edu Tue Jun 18 12:24:54 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id MAA30945; Tue, 18 Jun 1996 12:24:54 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id LAA28569; Tue, 18 Jun 1996 11:19:13 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id LAA26203 for ; Tue, 18 Jun 1996 11:19:09 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA05337; Tue, 18 Jun 96 11:19:06 EDT To: fitsbits at fits.cv.nrao.edu Date: Mon, 17 Jun 1996 16:43:09 -0700 From: Saleem Mukhtar Message-Id: <31C5ED8D.3A70 at aig.jpl.nasa.gov> Organization: Jet Propulsion Laboratory - Pasadena CA Path: solitaire.cv.nrao.edu!bofh.dot!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!enews.sgi.com!news.uoregon.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!swrinde!elroy.jpl.nasa.gov!nntp1.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!usenet References: <4poj1k$70q at hippo.ru.ac.za> Subject: SAOimage and FITS Newsgroups: sci.astro,sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Hello, I do not know anything about FITS and find the material on the web just to verbose. I want to convert an array of intergers to FITS format and vice versa. Please could someone help me. I would like to use C. I want to write a few "analysis" routines for SAOimage which output an image. Anybody tried this. If so, please could I take a look at your code. Thanks, Saleem From owner-fitsbits at tarsier.cv.nrao.edu Wed Jun 19 14:29:18 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA07041; Wed, 19 Jun 1996 14:29:18 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA07026; Wed, 19 Jun 1996 14:26:02 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id OAA07791 for ; Wed, 19 Jun 1996 14:25:55 -0400 (EDT) Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA10186 for ; Wed, 19 Jun 1996 14:25:52 -0400 (EDT) Received: (from pence at localhost) by tetra.gsfc.nasa.gov (LHEA9504/950407.s1) id OAA11168; Wed, 19 Jun 1996 14:24:35 -0400 Date: Wed, 19 Jun 1996 14:24:35 -0400 From: William Pence Message-Id: <199606191824.OAA11168 at tetra.gsfc.nasa.gov> To: fitsbits at fits.cv.nrao.edu Subject: Re: SAOimage and FITS Cc: pence at tetra.gsfc.nasa.gov Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Saleem Mukhtar wrote (Mon, 17 Jun 1996): > I want to convert an array of intergers to FITS format and vice versa. > Please could someone help me. I would like to use C. The CFITSIO package contains a set of relatively simple to use routines written in ANSI C for reading or writing FITS files. It is available on the Web at http://heasarc.gsfc.nasa.gov/docs/software/fitsio/fitsio.html or by anonymous ftp from legacy.gsfc.nasa.gov in the directory software/fitsio/c. This is still labeled as a 'beta' release, but it has been fully tested and is fully functional. This version will probably become the first full release within a couple weeks. Refer to the CFITSIO User's Guide for full details on building and using this C library. In particular refer to 'Basic Interface' chapter that describes the 16 basic routines that can perform most FITS file operations. There is also a sample program called cookbook.c that contains simple examples of how to use CFITSIO. -Bill Pence HEASARC/GSFC/NASA From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 20 10:07:50 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA16869; Thu, 20 Jun 1996 10:07:50 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id FAA16133; Thu, 20 Jun 1996 05:28:17 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id FAA14390 for ; Thu, 20 Jun 1996 05:28:08 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA13700; Thu, 20 Jun 96 05:28:02 EDT To: fitsbits at fits.cv.nrao.edu Date: Wed, 19 Jun 1996 14:52:03 GMT From: tdame at cfa.harvard.edu (Thomas Dame) Message-Id: Organization: Center for Astrophysics Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!interpath!news.sprintlink.net!news-fw-12.sprintlink.net!news.ultranet.com!homer.alpha.net!uwm.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!lerc.nasa.gov!purdue!oitnews.harvard.edu!cfanews!cfatmd.harvard.edu!tdame Subject: question on data padding Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk According to the FITS standard, the data array must be an integer multiple of 2880 bytes in length. To achieve this, Wells et al. (1981) states that: "The remainder of the last data array record after the last pixel of the array will be padded with zeros." When the data is stored as 16-bit integers (BITPIX=16), it is not clear to me whether the padding should be: a) integer zero (all bits zero) b) the integer representing zero intensity in the image (i.e., the integer I such that BZERO + I*BSCALE = 0). c) the integer BLANK I would guess Wells et al. mean case (a), but case (c) would seem like a better alternative, since integer zero can represent a perfectly reasonable intensity in the image. Admittedly this is a minor issue that should hardly ever matter, but I would like to follow the FITS standard. Many thanks, Tom Dame tdame at cfa.harvard.edu From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 20 11:51:21 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id LAA17525; Thu, 20 Jun 1996 11:51:21 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id LAA17447; Thu, 20 Jun 1996 11:48:49 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id LAA16927 for ; Thu, 20 Jun 1996 11:48:42 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA24102; Thu, 20 Jun 96 11:48:34 EDT To: fitsbits at fits.cv.nrao.edu Date: 19 Jun 1996 15:54:01 -0700 From: fitz at noao.edu (Mike Fitzpatrick) Message-Id: <4qa0e9$r5c at tucana.tuc.noao.edu> Organization: IRAF Project, National Optical Astronomy Observatories Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!venus.sun.com!cs.utexas.edu!ennfs.eas.asu.edu!noao!iraf!not-for-mail References: <31C5ED8D.3A70 at aig.jpl.nasa.gov> Subject: Re: SAOimage and FITS Newsgroups: sci.astro,sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk >From article <31C5ED8D.3A70 at aig.jpl.nasa.gov>, by Saleem Mukhtar : > I want to convert an array of intergers to FITS format and vice versa. > Please could someone help me. I would like to use C. > > I want to write a few "analysis" routines for SAOimage which output an > image. Anybody tried this. If so, please could I take a look at your code. If your only intention for writing FITS is to input it to SAOimage, you should know that SAOimage can handle raw binary as well. For instance, to display a raw binary file of long integers of 256x256 pixels try % saoimage -i4 256 256 file.raw Header info can also be skipped if needed along with other options. For more info see the SAOimage man page and User's Guide (available at ftp://iraf.noao.edu/contrib/saoimage.ps.Z ftp://iraf.noao.edu/contrib/saoman.ps.Z ftp://iraf.noao.edu/contrib/saodoc.tar.Z FITS of course lets you move more easily to other packages.... Mike Fitzpatrick NOAO/IRAF Group From owner-fitsbits at tarsier.cv.nrao.edu Fri Jun 21 10:01:09 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA23302; Fri, 21 Jun 1996 10:01:09 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id GAA23021; Fri, 21 Jun 1996 06:26:00 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id GAA24566 for ; Fri, 21 Jun 1996 06:25:51 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA04520; Fri, 21 Jun 96 06:25:45 EDT To: fitsbits at fits.cv.nrao.edu Date: 20 Jun 1996 16:34 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Message-Id: <20JUN199616342177 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!enews.sgi.com!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: Subject: Re: question on data padding Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article , tdame at cfa.harvard.edu (Thomas Dame) writes... >According to the FITS standard, the data array must be >an integer multiple of 2880 bytes in length. To achieve >this, Wells et al. (1981) states that: > > "The remainder of the last data array record after > the last pixel of the array will be padded with zeros." > >When the data is stored as 16-bit integers (BITPIX=16), it >is not clear to me whether the padding should be: > >a) integer zero (all bits zero) > >b) the integer representing zero intensity in the image > (i.e., the integer I such that BZERO + I*BSCALE = 0). > >c) the integer BLANK > > >I would guess Wells et al. mean case (a), In the NOST codification, which was reviewed by the community as part of the development process, this concept was expressed in the language, "the remainder of the record shall be filled with zero values with the same data representation as the values in the array," which is what is meant in case A. >but case (c) would >seem like a better alternative, since integer zero can represent >a perfectly reasonable intensity in the image. The values of NAXIS provide the size of the image, making it possible to distinguish those parts of the record in the array from those that are not. There are two interpretations that can be given to the phrase above, "the integer BLANK" 1) The ASCII BLANK, which is a *character*. 2) The value of the BLANK keyword. In the first case, the result would be to have the fill in a different format from the rest of the array, which would complicate the construction of reading programs. Following the same principle of consistency between fill and data, ASCII table data records, which consist of characters, are filled with ASCII blanks, while the fill at the end of binary tables has all bits set to zero. In the second, the BLANK keyword is optional, and thus no value may exist; also, the values of the blank keyword will also appear in the array. Barry M. Schlesinger FITS Support Office NSSDC/ADF From owner-fitsbits at tarsier.cv.nrao.edu Mon Jun 24 09:56:48 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA05166; Mon, 24 Jun 1996 09:56:48 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id XAA03135; Sun, 23 Jun 1996 23:51:52 -0400 Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id XAA12618 for ; Sun, 23 Jun 1996 23:51:49 -0400 (EDT) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10) with ESMTP id NAA02724 for ; Mon, 24 Jun 1996 13:51:34 +1000 Received: from grus.atnf.CSIRO.AU (localhost [127.0.0.1]) by grus.atnf.CSIRO.AU (8.6.12/8.6.12) with ESMTP id NAA08769 for ; Mon, 24 Jun 1996 13:51:28 +1000 Message-Id: <199606240351.NAA08769 at grus.atnf.CSIRO.AU> To: fitsbits at nrao.edu Subject: WCSLIB 2.3 Date: Mon, 24 Jun 1996 13:51:12 +1000 From: Mark Calabretta Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Release 2.3 of WCSLIB is now available via anonymous ftp from ftp.atnf.csiro.au:/pub/software/wcslib/wcslib-2.3.tar.gz Change logs for the C and FORTRAN libraries are appended. Mark Calabretta ATNF ------------------------------------------------------------------------------ C library ========= WCSLIB version 2.3 ------------------ * Fixed two bugs in zpnset() reported by David Berry (dsb at ast.man.ac.uk). The first led to an incorrect determination of the degree of the polynomial and would mainly have affected the efficiency of zpnrev(). The second affected the determination of the boundary of the projection but would only have been significant for projections with a point of inflection between 9 and 10 degrees of the pole. * Replaced usage of alloca() in lin.c with malloc() and free() for portability as suggested by Klaus Banse, ESO (kbanse at eso.org). * Allow for C implementations which provide their own versions of cosd(), sind(), tand(), acosd(), asind(), atand(), and atan2d(). From Klaus Banse, ESO (kbanse at eso.org). * Implemented the CUBEFACE axis for quadcube projections. * Made all function prototypes const-correct. * Adapted the header files to C++ usage. * Added a new test program, twcs1, to verify closure of wcsfwd() and wcsrev(). The old twcs test program is now called twcs2. * Added external arrays of error messages indexed by function return value. For example, extern const char *wcsmix_errmsg[] for wcsmix(). Messages for the many proj.c functions are in prjfwd_errmsg[], etc. WCSLIB version 2.2 ------------------ * Amended the projection equations for the conics (COP, COD, COE, COO) and Bonne's projection (BON) to correctly handle southern hemisphere projections with PROJP1 < 0 (reported by Lindsay Davis, NOAO). Revised tproj1 and tproj2 to test such cases. ------------------------------------------------------------------------------ FORTRAN library =============== WCSLIB version 2.3 ------------------ * Implemented the CUBEFACE axis for quadcube projections. * Added a new test program, TWCS1, to verify closure of WCSFWD and WCSREV. The old TWCS test program is now called TWCS2. WCSLIB version 2.2 ------------------ * Amended the projection equations for the conics (COP, COD, COE, COO) and Bonne's projection (BON) to correctly handle southern hemisphere projections with PROJP1 < 0 (reported by Lindsay Davis, NOAO). Revised TPROJ1 and TPROJ2 to test such cases. * Increased the dimension of the WCS array from WCS(0:2) to WCS(0:3) to allow for future handling of the CUBEFACE keyword - WCS(3) will store an index to the CUBEFACE axis. This affects the call sequences of WCSSET, WCSFWD, WCSREV, and WCSMIX. From owner-fitsbits at tarsier.cv.nrao.edu Mon Jun 24 09:56:05 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA05160; Mon, 24 Jun 1996 09:56:05 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id XAA29365; Fri, 21 Jun 1996 23:23:31 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id XAA02173 for ; Fri, 21 Jun 1996 23:23:26 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA12088; Fri, 21 Jun 96 23:23:24 EDT To: fitsbits at fits.cv.nrao.edu Date: 21 Jun 1996 12:02 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Message-Id: <21JUN199612022536 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!newsxfer2.itd.umich.edu!newsfeed.internetmci.com!news.msfc.nasa.gov!elroy.jpl.nasa.gov!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Subject: Software that supports binary tables conventions Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk As part of a revision of the User's Guide, the FITS Support Office is planning to include a list of publicly available software packages that support any or all of the proposed conventions for use with binary tables (Variable length arrays, Multidimensional arrays, substring arrays) that were in the appendixes to the paper. We currently know about FITSIO and the IDL Astronomy Users library. If you have another package that supports any of these conventions, and would be willing to have it mentioned in the User's Guide, let us know. Barry Schlesinger FITS Support Office GSFC/ADF From owner-fitsbits at tarsier.cv.nrao.edu Mon Jun 24 15:36:04 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA08496; Mon, 24 Jun 1996 15:36:04 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id PAA08441; Mon, 24 Jun 1996 15:32:44 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id PAA27699 for ; Mon, 24 Jun 1996 15:32:34 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA18007; Mon, 24 Jun 96 15:32:29 EDT To: fitsbits at fits.cv.nrao.edu Date: Mon, 24 Jun 1996 14:28:42 +0100 From: Peter Bunclark Message-Id: <31CE980A.319B at ast.cam.ac.uk> Organization: Royal Greenwich Observatory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!agate!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!news Subject: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk What is happening about the millenium? Is there any proposed way of dealing with the 2-digit original spec. of the year of observation. At the RGO, we have already digitized plates over a century old, and so the problem is current. One would not want (nor be allowed) to invalidate FITS readers expecting the original DATE-OBS keyword, so a suggestion is DATEOBS = '19960624' / YYYYMMDD Date with full year length. This format will keep us going until 9999 Dec 31, by which time we will have upgraded to FITS (Flexible Intergalactic Transport System). It is big-endian, so can be sorted ascii-betically; it is is a string so that a reader can go on to parse the year, month, day items; it is human-readable, and so complements Julian Date which is unambiguous. Another possiblility would be to complement DATE-OBS with CENT-OBS = 20, ie record the century of the observation. Does 20 mean this century or next? OBSERVER= 'Pete' / Peter Bunclark. From owner-fitsbits at tarsier.cv.nrao.edu Tue Jun 25 10:10:01 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA08129; Tue, 25 Jun 1996 10:10:01 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id BAA04899; Tue, 25 Jun 1996 01:19:04 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id BAA01707 for ; Tue, 25 Jun 1996 01:19:00 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA09884; Tue, 25 Jun 96 01:18:57 EDT To: fitsbits at fits.cv.nrao.edu Date: Mon, 24 Jun 1996 11:00:57 -0700 From: Ted Lane <71650.1205 at compuserve.com> Message-Id: <31CED7D9.E0 at compuserve.com> Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!enews.sgi.com!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!alterdial.uu.net!not-for-mail Subject: Any FITSIO class libraries? Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Does anyone know of any class libraries that have been built to do FITSIO for use in C++ programming? TIA From owner-fitsbits at tarsier.cv.nrao.edu Wed Jun 26 10:02:01 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA17656; Wed, 26 Jun 1996 10:02:01 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id AAA14402; Wed, 26 Jun 1996 00:08:23 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id AAA11106 for ; Wed, 26 Jun 1996 00:08:18 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA26586; Wed, 26 Jun 96 00:08:14 EDT To: fitsbits at fits.cv.nrao.edu Date: 25 Jun 1996 17:08 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Message-Id: <25JUN199617082483 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!cbgw3.att.com!news.PBI.net!news.mathworks.com!enews.sgi.com!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Subject: Sources of FITS Information Newsgroups: sci.astro.fits,sci.answers,news.answers Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Archive-name: astronomy/fits/info-sources Last-modified: 1996/06/25 -------- Sources of FITS Information Preface This material on sources of Flexible Image Transport System (FITS) information is posted and updated periodically by the FITS Support Office at the NASA Goddard Space Flight Center (GSFC). It discusses where general FITS information, including some answers to frequently asked questions, can be found, and provides sources for detailed information on FITS software and documentation. ------- FITS Support Office The FITS Support Office maintains a library of FITS information accessible from http://ssdoo.gsfc.nasa.gov/astro/fits/fits_home.html or ftp://nssdc.gsfc.nasa.gov/pub/fits/. The material available includes o "Definition of FITS," a codification of FITS for the NASA/Science Office of Standards and Technology (NOST), available in LaTeX, uncompressed PostScript, compressed PostScript and (usually) ASCII text (The ASCII text version may not be available for a short while after the announcement of a new version.) o "A User's Guide to FITS", published by the FITS Support Office, in LaTeX, and compressed and uncompressed PostScript o Revisions to version 1.0 of the "Definition of FITS" covering the specification of units that were incorporated into version 1.1 (text) o A current list of the extension type (structure) names registered with the International Astronomical Union FITS Working Group (IAUFWG) (text) o Rules for physical blocking on various media adopted by the IAUFWG (text) In the same directory, but accessible directly via http://ssdoo.gsfc.nasa.gov/astro/fits/basics_info.html is the FITS Basics and Information that used to be regularly posted to sci.astro.fits and sci.data.formats. It continues to be revised to reflect current FITS developments. It contains the following material: o An overview of FITS o A list of FITS documents o A list of software packages that support FITS, including FITS-image converters for various platforms o A list of on-line FITS resources o A description of the FITS Support Office The hypertext version provides links to many of the documents, software, and network locations listed. The text version provides information on how to obtain much of this material. There is also a hypertext version of the List of Registered Extensions. Links from the Web page and subdirectories of the ftp directory contain o Software developed by the FITS Support Office. o Error test files, primary HDUs useful for testing the ability of software designed to read FITS files to cope with files that have errors or are non-standard. These files should be downloaded in binary form. Printed copies of the material in the FITS directory can be obtained from the Coordinated Request and User Support Office (CRUSO): (Postal) Coordinated Request and User Support Office Code 633 National Space Science Data Center NASA Goddard Space Flight Center Greenbelt MD 20771 USA (Electronic mail) request at nssdca.gsfc.nasa.gov (Telephone) +1-301-286-6695 8:00 A. M. - 4:30 P.M. U. S. Eastern Time (-0500 from the last Sunday in October through the first Saturday in April; -0400 the remainder of the year) When no one is available, messages can be left on voice mail. (FAX) +1-301-286-1635 ------- National Radio Astronomy Observatory (NRAO) A FITS Archive can be found at URL http://fits.cv.nrao.edu/ or at ftp://fits.cv.nrao.edu/fits, located at NRAO. This machine supports a WAIS server named nrao-fits which has an index of all of the FITS-related text files in the archive; the file nrao-fits.src is available at think.com and at ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src. Some of the more noteworthy materials in this archive are o Drafts of proposed additions to the FITS standard and other drafts that may in the future be formally proposed o Text of any detailed proposals currently being discussed by the FITS committees o A collection of documents on World Coordinate Systems, including the current draft proposal o Conventions specific to particular projects or disciplines o Software packages for display of FITS images on Windows 3.1, Windows 95, Macintosh, and Unix/X-Windows o Other code for various environments and Usenet postings about code o Sample data and special test files designed to measure the ability of a FITS reader to handle a wide variety of FITS files o Archives of traffic on FITS-related newsgroups and exploders ------- HEASARC The NASA/Goddard High Energy Astrophysics Science Archive Research Center (HEASARC) Web server at http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html and the anonymous ftp access through ftp://heasarc.gsfc.nasa.gov/fits_info/ provide FITS material. HEASARC has developed a the FITSIO package of software routines for easily reading and writing FITS files, with a FORTRAN version and a beta test version in C, portable to a wide variety of machines. There is also the FTOOLS collection of software tools and the VERIFITS FITS conformance verifier. HEASARC software is available directly through http://heasarc.gsfc.nasa.gov/docs/heasarc/tech_res_software.html or ftp://heasarc.gsfc.nasa.gov/fits_info/software/ . The HEASARC server also provides information from the HEASARC FITS Working Group, (HFWG) the internal legislative body on FITS-related matters within the Office of Guest Investigator Programs (OGIP) at NASA/GSFC, at http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html or ftp://heasarc.gsfc.nasa.gov/fits_info/ . The HFWG has developed a number of FITS conventions that are more specific than the requirements of the FITS standards. Proposed conventions are publicized to the FITS community as a whole, with the goal of collaborative development of a set of conventions that will be accepted throughout the community as well as within OGIP/HEASARC. ------- Direct questions about this posting to Barry M. Schlesinger Coordinator, FITS Support Office Electronic mail: fits at nssdca.gsfc.nasa.gov Telephone: +1-301-441-4205 The FITS Support Office is operated under the guidance of the NASA/GSFC Astrophysics Data Facility. From owner-fitsbits at tarsier.cv.nrao.edu Wed Jun 26 10:05:23 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA17720; Wed, 26 Jun 1996 10:05:23 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id DAA16243; Wed, 26 Jun 1996 03:58:28 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id DAA12600 for ; Wed, 26 Jun 1996 03:58:24 -0400 (EDT) Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id DAA27823 for ; Wed, 26 Jun 1996 03:58:21 -0400 (EDT) Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3) id JAA05601; Wed, 26 Jun 1996 09:56:50 +0200 (MET DST) Message-Id: <199606260756.JAB12805 at ns2.hq.eso.org> Received: from localhost.hq.eso.org by ns2.hq.eso.org with SMTP (8.7.5/ eso-5.3) id JAB12805; Wed, 26 Jun 1996 09:56:49 +0200 (MET DST) To: fitsbits at fits.cv.nrao.edu Cc: psb at ast.cam.ac.uk Subject: Re: DATE-OBS='31/12/99' In-reply-to: Your message of "Mon, 24 Jun 96 14:28:42 BST." <31CE980A.319B at ast.cam.ac.uk> Date: Wed, 26 Jun 1996 09:56:45 +0200 From: Preben Grosbol Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk 'Peter Bunclark ' wrote: >What is happening about the millenium? Is there any proposed way of dealing >with the 2-digit original spec. of the year of observation. We at ESO have also started discussing this issue in the process of defining the output FITS format for the VLT. Internally, some proposals have been made, however, mostly in a style which does not ensure that old FITS readers would get it right. The only safe way seems to be define a new keyword with a more general format e.g. as in Peter Bunclarks proposal. I see not problems with name 'DATAOBS ' and known major organization which uses it with some other meaning but may be somebody turns up. For the value field YYYYMMDD, my main comment would be that ISO has defined a general date/time format (ISO 8601:1988/1991) which should be considered. If I remember right it also starts YYYYMMDD and is of string type but has an option for time. As soon as I get the printed copy of ISO 8601 I will check if it sensible for the value field of 'DATAOBS ' and post it. This keyword would be redundant considering 'MJD-OBS' but I do agree that a more readable format also should be available. Preben Grosbol From owner-fitsbits at tarsier.cv.nrao.edu Wed Jun 26 15:40:53 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA19403; Wed, 26 Jun 1996 15:40:53 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA19139; Wed, 26 Jun 1996 14:51:52 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id OAA16960 for ; Wed, 26 Jun 1996 14:51:34 -0400 (EDT) Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA06618 for ; Wed, 26 Jun 1996 14:51:28 -0400 (EDT) Received: (from pence at localhost) by tetra.gsfc.nasa.gov (LHEA9504/950407.s1) id OAA01099; Wed, 26 Jun 1996 14:50:12 -0400 Date: Wed, 26 Jun 1996 14:50:12 -0400 From: William Pence Message-Id: <199606261850.OAA01099 at tetra.gsfc.nasa.gov> To: fitsbits at fits.cv.nrao.edu Subject: HEAFITS mail exploder Cc: pence at tetra.gsfc.nasa.gov Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk HEAFITS - the High Energy Astrophysics FITS Mail Exploder --------------------------------------------------------- This is a reminder to the FITS community that an electronic mail server, called "heafits", is available to exchange information related to FITS data formats used within the high energy astrophysics community. The heafits mail exploder was established and widely used in 1993-94 but has not had much recent use. There is no strict charter for what topics may be discussed within the HEAFITS group, but in general, its purpose is to promote the development of standards for FITS files containing data related to high energy astrophysics. Topics of particular interest are: - proposed formats for data from new high energy astrophysical missions - proposals for new FITS keyword conventions or FITS table structures for different clases of high energy data files - question on what FITS keywords or table format should be used to store particular high energy data sets Anyone wishing to join this mail list may do so by sending a message to listserv at legacy.gsfc.nasa.gov in which the body of the mail message contains one line with the following text: subscribe heafits Your Name where 'Your Name' is obviously your own first and last name. Any communications to the heafits group should then be addressed to: heafits at legacy.gsfc.nasa.gov ---------------------------------------------------------------------- Bill Pence HEASARC/GSFC/NASA (301)286-4599 From owner-fitsbits at tarsier.cv.nrao.edu Wed Jun 26 15:41:53 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA19416; Wed, 26 Jun 1996 15:41:53 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA19214; Wed, 26 Jun 1996 14:57:36 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA17009 for ; Wed, 26 Jun 1996 14:57:26 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA23213; Wed, 26 Jun 96 14:57:21 EDT To: fitsbits at fits.cv.nrao.edu Date: Wed, 26 Jun 1996 10:01:52 +0100 From: Guy Rixon Message-Id: <31D0FC80.BB8 at ast.cam.ac.uk> Organization: Royal Greenwich Observatory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!spool.mu.edu!uwm.edu!news-res.gsl.net!news.gsl.net!nntp.coast.net!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!news.msfc.nasa.gov!elroy.jpl.nasa.gov!decwrl!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!news References: <31CE980A.319B at ast.cam.ac.uk> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Peter Bunclark wrote: > > What is happening about the millenium? Is there any proposed way of dealing > with the 2-digit original spec. of the year of observation. > > [detail deleted] > > One would not want (nor be allowed) to invalidate FITS readers expecting > the original DATE-OBS keyword, so a suggestion is > DATEOBS = '19960624' / YYYYMMDD Date with full year length. > > [more discussion deleted] I strongly support Pete's suggestion of a new keyword to take over from DATE-OBS in new files and agree that yyyymmdd is the best format. However, I'm not so sure that DATEOBS is the right keyword to use. I think to have two descriptors differing only by one character in the keyword and carrying almost but not quite identical information in the value field is dangerous. How about DATEFULL, or DATELONG, or even, since the yyyymmdd format is thought to be an ISO standard, DATE-ISO? -- Guy Rixon, gtr at ast.cam.ac.uk Software Engineering Group, Tel: +44-1223-374000 Royal Greenwich Observatory Fax: +44-1223-374700 From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 27 09:09:17 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA24627; Thu, 27 Jun 1996 09:09:17 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id TAA21601; Wed, 26 Jun 1996 19:40:34 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id TAA19026 for ; Wed, 26 Jun 1996 19:40:30 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA04470; Wed, 26 Jun 96 19:40:26 EDT To: fitsbits at fits.cv.nrao.edu Date: 26 Jun 1996 15:33:54 GMT From: seaman at noao.edu (Rob Seaman) Message-Id: <4qrl92$r5q at noao.edu> Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!venus.sun.com!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman References: <31CE980A.319B at ast.cam.ac.uk> <31D0FC80.BB8 at ast.cam.ac.uk> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Peter Bunclark wrote: > What is happening about the millenium? Is there any proposed way of > dealing with the 2-digit original spec. of the year of observation. Previous discussion has centered on related issues within the WCS proposal. Looking back through the half dozen or so messages that mention DATE-OBS, I see these keywords mentioned: MJD-OBS MJD-REF MJD-BEG MJD-AVG MJD-END MJD-WCS DATE-OBS TIME-OBS DATE-END TIME-END TIMEUNIT TIMESYS TIMEREF OBT_TIME DATE_OBS = 1995-11-16T21:21:15.721Z (The DATE_OBS format is stated to agree with ISO 8601 as endorsed by some group called the "Consultative Committee for Space Data Systems".) To be fair, these obviously represent several different solutions to the same set of problems, but these problems involve much more than providing a simple human (and machine) readable UT date. Perhaps in addition to a more rigorously correct keyword solution, a more straightforward year 2000 fix should indeed be provided for the simple astronomer-in-the-street. Given the deliberate way that FITS standards are considered, the WCS proposal may not be approved before the end of the millenium in any case :-) I suggest the DATE-OBS definition simply be relaxed to allow a four digit year as well as a two digit year: DATE-OBS= '24/06/96 ' / UT date DATE-OBS= '24/06/1996 ' / UT date A two digit year would imply a twentieth century date. The same rule could apply to DATE and other similar keywords. This agrees with the "once FITS, always FITS" rule since existing data are still fully legal. DATE-OBS is a reserved, but not a mandatory keyword, so the 8 character limit for fixed format strings is not required. Two digit years would not even need to be deprecated since archival data would continue to be analyzed. Question: Are there any examples (digitized plates, for instance) of nineteenth century FITS data? Any keyword changes should handle pre-twentieth century data also. (Someone else can suggest a solution for dates BC...) Note that "once FITS, always FITS" doesn't require that old software has to handle new data - this is also moot since any FITS code that cares about the date keywords will break at the millenium anyway. It may even be regarded as a feature since programmers should be encouraged to address the issue and users should be encouraged to update their software... This may even provide a new funding source! A recent U.S. congressional subcommittee meeting placed the cost of upgrading government software (to avert disaster) at 30 billion dollars. Who wants to start writing the grant proposal? Rob Seaman -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 27 09:09:56 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA24638; Thu, 27 Jun 1996 09:09:56 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id VAA22448; Wed, 26 Jun 1996 21:33:26 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA19765 for ; Wed, 26 Jun 1996 21:33:22 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA08229; Wed, 26 Jun 96 21:33:18 EDT To: fitsbits at fits.cv.nrao.edu Date: 26 Jun 1996 16:34:37 GMT From: sla at umbra.ucolick.org (Steve Allen) Message-Id: <4qroqt$7s4 at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory, Santa Cruz Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!venus.sun.com!ames!agate!darkstar.UCSC.EDU!umbra.ucolick.org!sla References: <31CE980A.319B at ast.cam.ac.uk> <31D0FC80.BB8 at ast.cam.ac.uk> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <31D0FC80.BB8 at ast.cam.ac.uk>, Guy Rixon wrote: >I strongly support Pete's suggestion of a new keyword to take over from >DATE-OBS in new files and agree that yyyymmdd is the best format. Take note, however, of the WCS draft paper at http://fits.cv.nrao.edu/documents/wcs/wcs.html which proposes to standardize the usage of MJD-OBS. This will work fine if the proposal also solves the backwards compatibility problem of existing FITS headers using different timescales. >How about DATEFULL, or DATELONG, or even, since the yyyymmdd format is thought >to be an ISO standard, DATE-ISO? A date format which does not also include the time of the observation increases the risk of "midnight" coding errors where the DATE and TIME are sampled on different "days". DATE-ISO does not distinguish between FITS 'DATE' and 'DATE-OBS'; i.e., between the date of the construction of the FITS header and the date when the data were acquired. However, it is a much more human-readable form than MJD. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 WWW: http://www.ucolick.org/~sla PGP public keys: see WWW From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 27 09:11:36 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA24657; Thu, 27 Jun 1996 09:11:36 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id DAA23588; Thu, 27 Jun 1996 03:05:59 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id DAA21999 for ; Thu, 27 Jun 1996 03:05:54 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA19469; Thu, 27 Jun 96 03:05:51 EDT To: fitsbits at fits.cv.nrao.edu Date: 26 Jun 1996 20:29:42 GMT From: seaman at noao.edu (Rob Seaman) Message-Id: <4qs6jm$7h8 at noao.edu> Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!news.iag.net!newsfeeder.sdsu.edu!newspump.sol.net!homer.alpha.net!uwm.edu!math.ohio-state.edu!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman References: <31CE980A.319B at ast.cam.ac.uk> <31D0FC80.BB8 at ast.cam.ac.uk> <4qroqt$7s4 at darkstar.UCSC.EDU> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Steve Allen writes: > Take note, however, of the WCS draft paper [...] which proposes to > standardize the usage of MJD-OBS. This will work fine if the proposal > also solves the backwards compatibility problem of existing FITS > headers using different timescales. Well, I'm not sure how the proposal could possibly do this. Each telescope and software package has traditionally had slightly (or grossly) different ideas about time. Hopefully the individual data providers can supply conversion tools to whatever standard may be established, but a lot of archival data was not acquired using an accurate (or accurately defined) clock in the first place. > A date format which does not also include the time of the observation > increases the risk of "midnight" coding errors where the DATE and TIME > are sampled on different "days". I agree with the spirit of this statement, but an unsegmented keyword doesn't remove the risk of these types of errors, since the keyword still has to be formatted from the system clock(s). On the other hand, having dual DATE-OBS/UT keywords (or whatever) isn't necessarily risky. Unix and other systems combine an unsegmented system time with builtin formatting routines. Ideally one would determine the unsegmented keyword (e.g., MJD-OBS) and derive the DATE-OBS and UT from that. MJD is not a very human friendly format, and many types of pilot processing errors are likely if readable calendar dates and clock times aren't immediately accessible to the scientist. > DATE-ISO does not distinguish between FITS 'DATE' and 'DATE-OBS'; i.e., > between the date of the construction of the FITS header and the date > when the data were acquired. However, it is a much more human-readable > form than MJD. By just allowing DATE as well as DATE-OBS (any others in wide usage?) to use 4 digit years in addition to the current 2 digit years, this problem is avoided. I suppose the HDU creation date could also be represented as MJD-HDU... Rob Seaman -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 27 09:14:04 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA24675; Thu, 27 Jun 1996 09:14:04 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id EAA24257; Thu, 27 Jun 1996 04:24:34 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id EAA22535 for ; Thu, 27 Jun 1996 04:24:30 -0400 (EDT) Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id EAA15507 for ; Thu, 27 Jun 1996 04:24:27 -0400 (EDT) Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3) id KAA10497; Thu, 27 Jun 1996 10:23:04 +0200 (MET DST) Date: Thu, 27 Jun 1996 10:23:02 +0200 (MET DST) Message-Id: <199606270823.KAA17492 at ns2.hq.eso.org> Received: by ns2.hq.eso.org (8.7.5/ eso-5.3) id KAA17492; Thu, 27 Jun 1996 10:23:02 +0200 (MET DST) From: pgrosbol at eso.org (Preben Grosbol) Subject: Re: DATE-OBS='31/12/99' To: fitsbits at fits.cv.nrao.edu Cc: seaman at noao.edu (Rob Seaman) X-Newsgroups: sci.astro.fits In-reply-to: <4qrl92$r5q at noao.edu> Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <4qrl92$r5q at noao.edu>, Rob Seaman wrote: > > I suggest the DATE-OBS definition simply be relaxed to allow a four > digit year as well as a two digit year: > > DATE-OBS= '24/06/96 ' / UT date > DATE-OBS= '24/06/1996 ' / UT date > > A two digit year would imply a twentieth century date. The same rule > could apply to DATE and other similar keywords. This agrees with the > "once FITS, always FITS" rule since existing data are still fully legal. > DATE-OBS is a reserved, but not a mandatory keyword, so the 8 character > limit for fixed format strings is not required. Two digit years would > not even need to be deprecated since archival data would continue to be > analyzed. Although the extension of the year to four digits would be an 'easy fix' it is not acceptable considering the FITS standard. In the NOST FITS document the definition is too clear to be changed i.e. 'YY [is] the last two digits of the year'. The original FITS paper Wells et al. (1981) was not so exact but the meaning is clear. It also states that 'Keywords beginning with the generic string DATE are used to document various relevant dates. Note that data value strings will be coded in the form 'dd/mm/yy' ...' > Note that "once FITS, always FITS" doesn't require that old software > has to handle new data - this is also moot since any FITS code that > cares about the date keywords will break at the millenium anyway. > It may even be regarded as a feature since programmers should be > encouraged to address the issue and users should be encouraged to > update their software... It may be reasonable with a few comments on the "once FITS, always FITS". The statement given in the NOST document section.9 is more exact namely: 'Any structure that is a valid FITS structure shall remain a valid FITS structure at all future times.' This would be violated if a 4 digit year would be allowed in the data value string. It is correct that 'old' FITS readers are not expected to handle 'new data'. However, they should not produce wrong results reading a new FITS file but rather skip new data structures (because they do not understand them). In the case of 4 digit years old readers may interpret the year as e.g. 1919 which would be unacceptable. Digitized plates may well be that old as Peter Bunclark indicated. Thus, a new keyword would be the only acceptable way considering the FITS standard. Evenso, the new keyword could not start with string 'DATE' as mentioned above (I should have checked more carefully before my first posting). I still support a more readable keyword than MJD-OBS to give time. Our internal software would in any case use MJD-OBS as time reference if it exists. The ISO 8601 seems a good candidate for a new date/time value string. With respect to the keyword name one could use 'OBS-DATE ' to avoid starting with 'DATE'. Preben Grosbol From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 27 13:33:23 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA26479; Thu, 27 Jun 1996 13:33:23 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id LAA25817; Thu, 27 Jun 1996 11:36:52 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id LAA25523 for ; Thu, 27 Jun 1996 11:36:46 -0400 (EDT) Received: from barnegat.gsfc.nasa.gov (barnegat.gsfc.nasa.gov [128.183.127.156]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id LAA20264 for ; Thu, 27 Jun 1996 11:36:42 -0400 (EDT) Received: from localhost by barnegat.gsfc.nasa.gov; (5.65/1.1.8.2/25Aug95-0336PM) id AA02754; Thu, 27 Jun 1996 11:35:07 -0400 Message-Id: <31D2AA2A.7A5F at barnegat.gsfc.nasa.gov> Date: Thu, 27 Jun 1996 11:35:06 -0400 From: Mike Corcoran X-Mailer: Mozilla 2.0 (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: fitsbits at fits.cv.nrao.edu Subject: Re: DATE-OBS='31/12/99' References: <31CE980A.319B at ast.cam.ac.uk> <31D0FC80.BB8 at ast.cam.ac.uk> <4qrl92$r5q at noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Rob Seaman wrote: > > I suggest the DATE-OBS definition simply be relaxed to allow a four > digit year as well as a two digit year: > > DATE-OBS= '24/06/96 ' / UT date > DATE-OBS= '24/06/1996 ' / UT date > In general I don't like altering definitions of keyword values of previously standardized keywords, since this can cause problems. For example some poor guy might have a FITS reader which extracts only the 1st 8 characters from DATE-OBS, and if so 24/06/19 & 24/06/1996 would be confused. I don't know of any such poorly written code (I of course would never write any!) but it may be lurking out there somewhere. A better approach in this spirit would be to explicitly define the year in a totally new keyword (YEAR-OBS or some such). I.e. YEAR-OBS='1996 ' / year corresponding to DATE-OBS Absence of YEAR-OBS would imply the 20th century. This is similar to Peter Bunclark's CENT-OBS but without the ambiguity of whether 20 means yr+2000 or 20th century. my $0.02 Mike -- *********************************************************** Dr. Michael F. Corcoran High Energy Astrophysics Science Archive Research Center Goddard Space Flight Center Greenbelt, MD 20771 corcoran at barnegat.gsfc.nasa.gov LHEAVX::CORCORAN http://lheawww.gsfc.nasa.gov/users/corcoran/bio.html *********************************************************** From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 27 16:17:35 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA27162; Thu, 27 Jun 1996 16:17:35 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id QAA27129; Thu, 27 Jun 1996 16:15:37 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id QAA27623 for ; Thu, 27 Jun 1996 16:15:30 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA16478; Thu, 27 Jun 96 16:15:25 EDT To: fitsbits at fits.cv.nrao.edu Date: Thu, 27 Jun 1996 10:23:20 +0100 From: Guy Rixon Message-Id: <31D25308.675F at ast.cam.ac.uk> Organization: Royal Greenwich Observatory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!gatech!rutgers!sgigate.sgi.com!news-res.gsl.net!news.gsl.net!nntp.coast.net!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!news References: <31CE980A.319B at ast.cam.ac.uk> <31D0FC80.BB8 at ast.cam.ac.uk> <4qroqt$7s4 at darkstar.UCSC.EDU> <4qs6jm$7h8 at noao.edu> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Rob Seaman wrote: > > Ideally one would determine the unsegmented keyword (e.g., MJD-OBS) and > derive the DATE-OBS and UT from that. MJD is not a very human friendly > format, and many types of pilot processing errors are likely if readable > calendar dates and clock times aren't immediately accessible to the > scientist. Ok then, how about this: use MJD-OBS as the standard, machine-readable date descriptor, but always encode in its _comment_ the human-readable date and time. Then throw away DATE-OBS. -- Guy Rixon, gtr at ast.cam.ac.uk Software Engineering Group, Tel: +44-1223-374000 Royal Greenwich Observatory Fax: +44-1223-374700 From owner-fitsbits at tarsier.cv.nrao.edu Thu Jun 27 18:45:37 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA28575; Thu, 27 Jun 1996 18:45:37 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id SAA28556; Thu, 27 Jun 1996 18:41:07 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id SAA28734 for ; Thu, 27 Jun 1996 18:41:01 -0400 (EDT) Received: from noao.edu (noao.edu [140.252.1.54]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id SAA27023 for ; Thu, 27 Jun 1996 18:36:11 -0400 (EDT) Received: from tucana.tuc.noao.edu (tucana.tuc.noao.edu [140.252.1.1]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id PAA19324; Thu, 27 Jun 1996 15:32:38 -0700 (MST) Received: by tucana.tuc.noao.edu (4.1/SAG.sat.14) id AA28584; Thu, 27 Jun 96 15:31:53 MST; for pgrosbol at eso.org Date: Thu, 27 Jun 96 15:31:53 MST From: seaman at noao.edu (Rob Seaman) Message-Id: <9606272231.AA28584 at tucana.tuc.noao.edu> To: fitsbits at fits.cv.nrao.edu Subject: Re: DATE-OBS='31/12/99' Cc: pgrosbol at eso.org Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Preben makes good points about FITS DATExxxx keywords - however, I continue to reach a different conclusion. Extending the definition of DATE-OBS, and of the DATE "class" in general, preserves the integrity of FITS better than deprecating an entire class of keywords and replacing them with something else. More to the point, it preserves the integrity of the terabytes of twentieth century data that the community has carefully observed, analyzed and archived. It will also be much simpler to implement. > In the NOST FITS document the definition is too clear to be changed > i.e. 'YY [is] the last two digits of the year'. The definition wouldn't be changed, it would be extended. For two digit year fields, the definition would simply be clarified as referring to twentieth century dates. After all, this was clearly the original intent. > The original FITS paper Wells et al. (1981) was not so exact but the > meaning is clear. It also states that 'Keywords beginning with the > generic string DATE are used to document various relevant dates. Note > that data value strings will be coded in the form 'dd/mm/yy' ...' The elided text continues '... (which is as good a system as any of the others) ...' I mention this not to provoke laughter (well, not *only* that), but to point out that the current discussion is just a continuation of one the founding authors started. Their original solution to this problem was not even a bad one. Millions of lines of financial code will have to be changed to avoid economic ruin at the millennium. FITS just requires a slight clarification and extension. > 'Any structure that is a valid FITS structure shall remain a valid > FITS structure at all future times.' > This would be violated if a 4 digit year would be allowed in the data > value string. It is correct that 'old' FITS readers are not expected > to handle 'new data'. However, they should not produce wrong results > reading a new FITS file but rather skip new data structures (because > they do not understand them). There would be no violation - and old software that cares about the date can't just "skip" the fact that the keyword won't be meaningful anymore. > Thus, a new keyword would be the only acceptable way considering the > FITS standard. Evenso, the new keyword could not start with string > 'DATE' as mentioned above and later: > With respect to the keyword name one could use 'OBS-DATE ' to avoid > starting with 'DATE'. Note the necessary conclusion to be drawn. Not only would "OBS-DATE" replace "DATE-OBS", but the entire class of DATExxxx keywords would be deprecated. This is a major change to the FITS standard and requires much larger modifications to current software than simply adding 2 digits to the year when the original keywords are written. With the DD/MM/YYYY modification, reading a FITS file would just require adding an if-else clause when creating the same internal 4 digit year (or unsegmented time) that the software will continue to use. Support for current data would be guaranteed since unmodified software will continue to work. Support for new data would be simple to achieve. With any of the "new keyword" proposals, especially ones that change the information content (as with ISO 8601), reading a FITS file would involve some logic that would have to prefer OBS-DATE over DATE-OBS (or the reverse) and a similar hierarchy for each DATExxxx keyword in turn. Individual programmers would choose the keyword precedence for their own code. Large systems may not even agree from one module to the next. Different systems by different groups would certainly drift apart. Writing a FITS file would have even larger implications. At some point (that would vary from institution to institution and between software package), a massive discontinuity would occur in the data record. This discontinuity won't even be finished on 1 Jan 2000, since individuals would undoubtedly continue to use the old keywords into the following decade. Even if the DATE class keywords are deprecated, they will remain legal FITS. Is it reasonable (or useful) to allow DD/MM/YY dates to represent 21st century dates? Or will this same discussion recur in 2096? > I still support a more readable keyword than MJD-OBS to give time. Amen to that. If "once FITS, always FITS" is the first law of FITS, then "keep it simple" is the zeroth law. As an alternative, Guy Rixon has suggested: > use MJD-OBS as the standard, machine-readable date descriptor, but > always encode in its _comment_ the human-readable date and time. MJD and ISO 8601 are useful standards - however, they address different problems than DATE-OBS. Comments shouldn't be used to store information that users will want to use for header listings and boolean queries. ...and Mike Corcoran writes: > A better approach in this spirit would be to explicitly define the year > in a totally new keyword (YEAR-OBS or some such). [...] Absence of > YEAR-OBS would imply the 20th century. This is similar to Peter > Bunclark's CENT-OBS but without the ambiguity of whether 20 means > yr+2000 or 20th century. There is no advantage in preserving the current imprecise DATE-OBS format at all costs. Human readability suffers with this approach - there is no way to guarantee that YEAR-OBS would immediately follow DATE-OBS in the header. Even if it does, one or the other keyword may easily scroll out of a window, or fall on the wrong side of a page break. Every DATExxxx class keyword would also require a corresponding YEARxxxx keyword. Do we really want to reserve an entirely new class of keywords? We would either have to deprecate all prior keyword usage starting with "YEAR", or just reserve YEAR-OBS and deprecate all "DATE" keywords other than DATE-OBS. Prior discussion has centered on preserving FITS usage while introducing unsegmented time standards (MJD or ISO 8601, for instance). Separate YEARxxxx or CENTxxxx keywords segment the time even further. Whatever solution is adopted should be graceful, not just functional. If functionality were the final word, I would instead advocate a variation on DD/MM/YYYY: DATE-OBS= '24/06/96/19 ' This would undoubtedly break less current software and offers precisely the same information, but aesthetically it's indefensible. Not "breaking" software is also not the same as not requiring software to change - the millennium would still leave us with DATE-OBS='01/01/00/20' to deal with. Rob seaman at noao.edu From owner-fitsbits at tarsier.cv.nrao.edu Fri Jun 28 09:26:02 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA32320; Fri, 28 Jun 1996 09:26:02 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id WAA29622; Thu, 27 Jun 1996 22:19:24 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id WAA00158 for ; Thu, 27 Jun 1996 22:19:20 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA29862; Thu, 27 Jun 96 22:19:17 EDT To: fitsbits at fits.cv.nrao.edu Date: 27 Jun 1996 18:17:48 GMT From: sla at umbra.ucolick.org (Steve Allen) Message-Id: <4quj8c$5jq at darkstar.UCSC.EDU> Organization: UCO/Lick Observatory, Santa Cruz Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!spool.mu.edu!agate!darkstar.UCSC.EDU!umbra.ucolick.org!sla References: <31CE980A.319B at ast.cam.ac.uk> <31D0FC80.BB8 at ast.cam.ac.uk> <4qrl92$r5q at noao.edu> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <4qrl92$r5q at noao.edu>, Rob Seaman wrote: >Question: Are there any examples (digitized plates, for instance) >of nineteenth century FITS data? Give me a moment to run over to the archives and I'll make one :-) More seriously, doing this right in an archival sense involves significant historical research into the (often unwritten) conventional assumptions of the era. Without doing that it is pretty likely that a modern interpretation of the logbooks will presume something wrong. And in that case the FITS file should contain something that will prevent naive machine interpretation of the data. I've run into quite a bit of that as I dug through the archives finding the history of the published positions of Lick Observatory. The adopted longitude value is directly related to the time standards at Lick, but there's also the issues of why GMT did not equal UT and other international conventions which were initially used with suboptimal inputs. Having the history of the adopted positions in hand I *might* be able to disentangle the TIMESYS assumptions inherent in the 19th century Lick plates -- at least for some of the observers. > Any keyword changes should handle >pre-twentieth century data also. (Someone else can suggest a solution >for dates BC...) Already available. 1 AD follows 1BC, but astronomically 1BC is year 0. If this is an issue for FITS, however, then we would first need to consider a CALENSYS keyword with values such as 'JULIAN', 'GREGORIAN', and 'ORTHODOX' so that we can encode the DATE-OBS information from 19th century Russian plates. With this in hand it should be possible to scan Galileo's notebooks and convert them to FITS images with correct WCS information. I am being facetious with the CALENSYS suggestion, but interpretation of the archival record of planetary observations demands the TIMESYS keyword. Values for the TIMESYS keyword in archival material could include locally relevant tags such as the name of the observer at the Meridian Circle who was then setting the clocks. The value of TIMESYS not being one of a few certified-machine-interpretable choices would serve both to document historically and to prevent automated misinterpretation. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 WWW: http://www.ucolick.org/~sla PGP public keys: see WWW From owner-fitsbits at tarsier.cv.nrao.edu Fri Jun 28 09:26:40 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA32332; Fri, 28 Jun 1996 09:26:40 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id XAA29863; Thu, 27 Jun 1996 23:42:04 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id XAA00781 for ; Thu, 27 Jun 1996 23:42:00 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA03101; Thu, 27 Jun 96 23:41:57 EDT To: fitsbits at fits.cv.nrao.edu Date: 27 Jun 1996 19:13:29 GMT From: valdes at tucana.tuc.noao.edu (Frank Valdes) Message-Id: <4qumgp$avn at noao.edu> Organization: IRAF Project, National Optical Astronomy Observatories Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!news.iag.net!newsfeeder.sdsu.edu!newspump.sol.net!spool.mu.edu!uwm.edu!math.ohio-state.edu!cs.utexas.edu!ennfs.eas.asu.edu!noao!usenet References: <199606270823.KAA17492 at ns2.hq.eso.org> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk I know I will be critized for the following but we are starting to sound more like lawyers than astronomers. In article <199606270823.KAA17492 at ns2.hq.eso.org>, pgrosbol at eso.org (Preben Grosbol) writes: From: pgrosbol at eso.org (Preben Grosbol) Subject: Re: DATE-OBS='31/12/99' > Although the extension of the year to four digits would be an 'easy fix' > it is not acceptable considering the FITS standard. In the NOST > FITS document the definition is too clear to be changed i.e. 'YY [is] the > last two digits of the year'. The original FITS paper Wells et al. (1981) > was not so exact but the meaning is clear. It also states that 'Keywords > beginning with the generic string DATE are used to document various relevant > dates. Note that data value strings will be coded in the form 'dd/mm/yy' ...' > It may be reasonable with a few comments on the "once FITS, always FITS". > The statement given in the NOST document section.9 is more exact namely: > 'Any structure that is a valid FITS structure shall remain a valid > FITS structure at all future times.' > This would be violated if a 4 digit year would be allowed in the data value > string. It is correct that 'old' FITS readers are not expected to handle > 'new data'. However, they should not produce wrong results reading a new > FITS file but rather skip new data structures (because they do not understand > them). > In the case of 4 digit years old readers may interpret the year as e.g. > 1919 which would be unacceptable. Digitized plates may well be that old > as Peter Bunclark indicated. Will there really be "old" FITS readers in 2000? In terms of making a wrong interpretation the "old" FITS reader, illustrated above, using only two digits for the year will interpret 1/1/00 as 1900 when 2000 is intended which is also quite wrong. The "old" unmodified reader will not have been changed to understand any of the other keywords being proposed. There are many reasonable suggestions but as an astronomer rather than a lawyer I think continued use of DATE-OBS or any DATE keyword with the simple change that years are four digits except that when two digits are encountered the century is 1900 is desirable and we have several years to fix "old" readers which will make a mistake regardless of what is done. For a new keyword I would wish to see an ascii orderable and human readable value. The ISO standard seems reasonable. The keyword might be DATE-ISO. The question about separate dates for the date the file is created and the date relevant to the data is another quibble that has little basis in reality. I have yet to find a reason to be interested in the date the file is created. The interest for an astronomer is the date to be applied to the data. So except for the currently used practice of DATE any additional dates/times should be considered to apply to the data. When exactly (beginning of an integration, etc.) needs to be specified by the data creator in some way with keywords, comments to keywords, or an archived data dictionary specification. This does not prevent data creators from indicating the date the file was written if they feel the need. I support use of MJD time stamps (such as MJD-OBS) but it is not a substitute for a date/time that can be parsed by a human without a calculator. Frank Valdes From owner-fitsbits at tarsier.cv.nrao.edu Fri Jun 28 09:27:32 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA32348; Fri, 28 Jun 1996 09:27:32 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id DAA30756; Fri, 28 Jun 1996 03:31:23 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id DAA02297 for ; Fri, 28 Jun 1996 03:31:18 -0400 (EDT) Received: from poseidon.ifctr.mi.cnr.it (poseidon.ifctr.mi.cnr.it [155.253.2.87]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id DAA02151 for ; Fri, 28 Jun 1996 03:31:14 -0400 (EDT) Received: by poseidon.ifctr.mi.cnr.it (5.65/1.34) id AA00530; Fri, 28 Jun 1996 09:35:17 +0200 Organization: Istituto di Fisica Cosmica e Tecnologie Relative Date: Fri, 28 Jun 1996 09:35:16 +0200 (MET DST) From: Lucio Chiappetti Subject: Re: DATE-OBS='31/12/99' To: fitsbits at fits.cv.nrao.edu In-Reply-To: <31D2AA2A.7A5F at barnegat.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk On Thu, 27 Jun 1996, Mike Corcoran wrote: > A better approach in this spirit would be to explicitly define the year in a > totally new keyword (YEAR-OBS or some such). I.e. > > YEAR-OBS='1996 ' / year corresponding to DATE-OBS > > Absence of YEAR-OBS would imply the 20th century. This is similar to Peter > Bunclark's CENT-OBS but without the ambiguity of whether 20 means yr+2000 or > 20th century. Could one instead not assume that 2-digit dates refer to the year interval from 1979 to 2079 (since FITS was invented on 28 march 79 as Don Wells reminds us every year), or perhaps from 1970 to 2070 (to match with the fact that "Unix internal time" is kept in seconds since 1970 [by the way THAT 32-bit counter will also recycle sometimes] ? Surely the amount of FITS data pre-dating 197x will be limited ... [archival researchers don't shoot me] This will give us some more time ... ---------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR | Ma te' vugl' da' quost avis a ti' Orsign via Bassini 15 - I-20133 Milano | Buttet rabios intant te se' pisnign Internet: LUCIO at IFCTR.MI.CNR.IT | (Rabisch, II 46, 119-120) ---------------------------------------------------------------------------- For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html ---------------------------------------------------------------------------- From owner-fitsbits at tarsier.cv.nrao.edu Fri Jun 28 09:30:47 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA32379; Fri, 28 Jun 1996 09:30:47 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id IAA32212; Fri, 28 Jun 1996 08:24:52 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id IAA03987 for ; Fri, 28 Jun 1996 08:24:47 -0400 (EDT) Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id IAA04384 for ; Fri, 28 Jun 1996 08:24:40 -0400 (EDT) Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3) id OAA27609; Fri, 28 Jun 1996 14:23:14 +0200 (MET DST) Message-Id: <199606281223.OAB02646 at ns2.hq.eso.org> Received: from localhost.hq.eso.org by ns2.hq.eso.org with SMTP (8.7.5/ eso-5.3) id OAB02646; Fri, 28 Jun 1996 14:23:13 +0200 (MET DST) To: fitsbits at fits.cv.nrao.edu Cc: seaman at noao.edu (Rob Seaman) Subject: Re: DATE-OBS='31/12/99' In-reply-to: Your message of "Thu, 27 Jun 96 15:31:53 MST." <9606272231.AA28584 at tucana.tuc.noao.edu> Date: Fri, 28 Jun 1996 14:23:11 +0200 From: Preben Grosbol Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Rob Seaman writes: >Whatever solution is adopted should be graceful, not just functional. >If functionality were the final word, I would instead advocate a >variation on DD/MM/YYYY: > > DATE-OBS= '24/06/96/19 ' > >This would undoubtedly break less current software and offers precisely >the same information, but aesthetically it's indefensible. Not "breaking" >software is also not the same as not requiring software to change - the >millennium would still leave us with DATE-OBS='01/01/00/20' to deal with. It is very important not to fool old FITS readers. Thus, the first 8 characters of data value strings for 'DATExxxx' keywords must be maintained as 'dd/mm/yy'. I agree with Rob that the double keyword solutions e.g. 'CENTxxxx' have a number of disadvantages. Also a whole set of new e.g. ISO8601 formated data keywords may be too much. Although it may not be so 'graceful' Rob's proposal to add additional charaters may be the less harmfull. To make it a little more readable I would rather suggest something like: DATA-OBS= '24/12/01:2001' It is redundant but more readable. It would make it reasonable easy to specify a backward compatible rule e.g. 'Date value strings which have 8 character or have no ':' as their 9th character specify a date in the 20th century (i.e. 19yy). If the 9th character is ':', the full year follows as an integer.' Preben Grosbol From owner-fitsbits at tarsier.cv.nrao.edu Fri Jun 28 18:22:05 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA04007; Fri, 28 Jun 1996 18:22:05 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA01917; Fri, 28 Jun 1996 14:46:21 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id OAA06754 for ; Fri, 28 Jun 1996 14:46:15 -0400 (EDT) Received: from noao.edu (noao.edu [140.252.1.54]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id OAA13022 for ; Fri, 28 Jun 1996 14:44:02 -0400 (EDT) Received: from tucana.tuc.noao.edu (tucana.tuc.noao.edu [140.252.1.1]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id LAA18807 for ; Fri, 28 Jun 1996 11:42:39 -0700 (MST) Received: by tucana.tuc.noao.edu (4.1/SAG.sat.14) id AA24869; Fri, 28 Jun 96 11:42:38 MST; for fitsbits at fits.cv.nrao.edu Date: Fri, 28 Jun 96 11:42:38 MST From: seaman at noao.edu (Rob Seaman) Message-Id: <9606281842.AA24869 at tucana.tuc.noao.edu> To: fitsbits at fits.cv.nrao.edu Subject: Re: DATE-OBS='31/12/99' Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Peter Bunclark's summary is quite useful. I'll respond first to a few points from Preben's and Lucio's latest posts. Preben says: > It is very important not to fool old FITS readers. Thus, the first > 8 characters of data value strings for 'DATExxxx' keywords must be > maintained as 'dd/mm/yy'. But no matter what we do, the millennium will arrive and current FITS software will be fooled. The software has to change. Period. That being the case, let's change it to both preserve (actually, enhance) the integrity of current data, as well as to improve the quality (machine and human oriented) of future data. > Although it may not be so 'graceful' Rob's proposal to add additional > charaters may be the less harmfull. To make it a little more readable > I would rather suggest something like: > > DATA-OBS= '24/12/01:2001' This is better than my offhand suggestion, but I find either alternative unacceptable. 'Graceful' is just a synonym for human-friendly. Users have to not just read this keyword, but write it as well upon occasion. They have to use the date for generating queries and to format listings. A date is a pretty fundamental piece of information to allow to be so awkward. Lucio says: > Could one instead not assume that 2-digit dates refer to the year > interval from 1979 to 2079 [...] This will give us some more time ... Please, no...let's fix the problem right. Do we want to have to deal with this until we die? Peter follows his summary with his own suggestions: > 1) We've been discussing at length the problem of a 2-digit year; also, > the slashes are redundant, the day-month-year order is confusing to > Americans (easily done), and the order is little-endian. While date formats such as 19960628 are appropriate in various machine generated identifiers, a human readable format needs punctuation. I also suspect that concern for Americans isn't central to your argument :-) > 2) I would deprecate DATE-OBS from 1/1/2000; if FITS writers leave it out, > then old FITS readers won't misinterpret it. Just deprecating the keyword isn't good enough. If we're concerned about current software, we have to fix the current problem. The fix should be as straightforward as possible, and in particular should not involve extraneous solutions (like MJD) to other problems. > 3) DATE-OBS = 'dd/mm/yyyy' is going to cause a lot of grief to old > software. And much of this old software is sitting on old systems > in operational situations and nobody dares touch it... Somebody will *have* to touch it! A four digit year will cause no more grief than just waiting for 1 January 2000 to arrive. On the other hand, explicitly clarifying the current two digit year format as referring to twentieth century dates is necessary to preserve the integrity of archival data. The dates recorded in the FITS files that we've already carefully stored away should not be allowed to become ambiguous. A straw proposal: 1) redefine DATE-OBS = 'DD/MM/YYYY' 2) deprecate DATE-OBS as of midnight 31 December 1999 3) implement OBS-DATE (or DATEOBS, or whatever) with a simple human-oriented date format to be determined 4) implement MJD-OBS as a separate issue The DATE keyword would be handled similar to DATE-OBS. Are there other DATExxxx keywords to worry about? Note that #2 and #3 are only called for if the format is really as offensive to the community as some have said. A better proposal: 1) redefine DATE-OBS = 'DD/MM/YYYY' (but write DD/MM/YY until 01/01/2000) 2) implement DATE-ISO, which takes precedence if both are present Rob seaman at noao.edu From owner-fitsbits at tarsier.cv.nrao.edu Sun Jun 30 14:09:02 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA05492; Sun, 30 Jun 1996 14:09:02 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id VAA05284; Fri, 28 Jun 1996 21:07:45 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA09376 for ; Fri, 28 Jun 1996 21:07:39 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA19894; Fri, 28 Jun 96 21:07:36 EDT To: fitsbits at fits.cv.nrao.edu Date: Fri, 28 Jun 1996 15:21:55 +0100 From: Peter Bunclark Message-Id: <31D3EA83.297F at ast.cam.ac.uk> Organization: Royal Greenwich Observatory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!interpath!news.sprintlink.net!news-fw-12.sprintlink.net!news.ultranet.com!homer.alpha.net!uwm.edu!newsfeed.internetmci.com!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!lyra.csx.cam.ac.uk!news References: <31CE980A.319B at ast.cam.ac.uk> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Time for a summary. My original message was to ask for something to be done about the lack of a century in the DATE-OBS format. I pointed out that the problem has been current for some time, since we already really do produce FITS tapes of date spanning more than a century. My suggestions of DATEOBS and CENT-OBS were only ideas, not strong proposals. Guy Rixon doesn't like those DATEOBS and suggests DATEFULL or DATELONG or DATE-ISO. Rob Seaman came up with a bunch from the WCS discussion: MJD-OBS MJD-REF MJD-BEG MJD-AVG MJD-END MJD-WCS DATE-OBS TIME-OBS DATE-END TIME-END TIMEUNIT TIMESYS TIMEREF OBT_TIME DATE_OBS = 1995-11-16T21:21:15.721Z but he suggests extending DATE-OBS to allow a 4-digit year. Mike Corcoran doesn't want to mess with DATE-OBS and suggests adding YEAR-OBS. Steve Allen expands the quest to timescales both longer and shorter than my original ideasr, and he goes over the argument for MJD-OBS being definitive but not human-readable. Guy then suggests standardizing on MJD-OBS and throwing away DATE-OBS. Preben Grosbol comes in with general agreement, and promises to post the ISO 8601:1988/1991 general time format. Preben next argues not to violate the original DATE-OBS, nor even the DATE... format and suggests OBS-DATE. Frank Valdes comes in with the assurance that by 2000 old FITS readers can be modified where necessary. He supports both MJD-OBS and a human- readable ISO date. Rob then returns, disagreeing with Prebeb by saying that of course we can alter the definition of DATE-OBS, and points out one of the shortcomings of Wells et al (1981) (PAPER ONE). In conclusion, we all agree there is a problem to be fixed, but not on much else. I would like to add some further points: 1) PAPER ONE did contain a few howlers (EPOCH being the most celebrated), and so cannot be considered inviolate. The phrase "the form 'dd/mm/yy' (which is as good a system as any of the others)" is not only incredibly flippant in the context, but quite inaccurate. We've been discussing at length the problem of a 2-digit year; also, the slashes are redundant, the day-month-year order is confusing to Americans (easily done), and the order is little-endian. 2) I would deprecate DATE-OBS from 1/1/2000; if FITS writers leave it out, then old FITS readers won't misinterpret it. 3) DATE-OBS = 'dd/mm/yyyy' is going to cause a lot of grief to old software. And much of this old software is sitting on old systems in operational situations and nobody dares touch it... 4) I feel strongly the proposed new format should be most-significant first; it is convenient in many situations to be able to do a meaningful sort on the ascii collating sequence. 5) I feel strongly about the FITS standard, despite its various shortcomings (8-character keywords is my favourite, right up there with the lack of an unsigned data-type). However, we're about to write a new FITS writer for a major observatory (ING La Palma) and will not let it out with the century ambiguity outstanding; any chance of reaching a consensus here? Cheers, Pete. From owner-fitsbits at tarsier.cv.nrao.edu Sun Jun 30 14:20:52 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA05541; Sun, 30 Jun 1996 14:20:52 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id GAA07847; Sat, 29 Jun 1996 06:28:25 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id GAA12961 for ; Sat, 29 Jun 1996 06:28:16 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA06734; Sat, 29 Jun 96 06:28:11 EDT To: fitsbits at fits.cv.nrao.edu Date: Fri, 28 Jun 1996 00:01:33 GMT From: svoynick at netcom.com (Stan Voynick) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!spool.mu.edu!uwm.edu!cs.utexas.edu!swrinde!newsfeed.internetmci.com!news.sprintlink.net!news-stk-200.sprintlink.net!news2.noc.netcom.net!noc.netcom.net!netcom.com!svoynick References: Subject: Re: question on data padding Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk While I have generally assumed that all remaining bytes in the file should be zero, regardless of the data format (equivalent to your option (a)), I wanted to point out that your option (b) is not a feasible interpretation anyway, as I often use BSCALE/BZERO scalings for our 16-bit images in which no integer value even comes close to mapping to "zero intensity" after being scaled by BSCALE and BZERO. - Stan Voynick - In article , Thomas Dame wrote: >According to the FITS standard, the data array must be >an integer multiple of 2880 bytes in length... [.. snip ..] > >When the data is stored as 16-bit integers (BITPIX=16), it >is not clear to me whether the padding should be: > >a) integer zero (all bits zero) > >b) the integer representing zero intensity in the image > (i.e., the integer I such that BZERO + I*BSCALE = 0). > >c) the integer BLANK From owner-fitsbits at tarsier.cv.nrao.edu Sun Jun 30 14:21:15 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA05554; Sun, 30 Jun 1996 14:21:15 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id IAA08170; Sat, 29 Jun 1996 08:55:56 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id IAA13817 for ; Sat, 29 Jun 1996 08:55:51 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA10365; Sat, 29 Jun 96 08:55:48 EDT To: fitsbits at fits.cv.nrao.edu Date: 28 Jun 1996 18:54:48 GMT From: Pierre Maxted Message-Id: <4r19po$d6f at infa.central.susx.ac.uk> Organization: Sussex University Astronomy Centre Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!spool.mu.edu!uwm.edu!cs.utexas.edu!bcm.tmc.edu!pendragon!news.msfc.nasa.gov!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!sunsite.doc.ic.ac.uk!susx.ac.uk!usenet Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk -- Preben Grosbol wrote: : : : > It is very important not to fool old FITS readers. Thus, the first >8 characters of data value strings for 'DATExxxx' keywords must be >maintained as 'dd/mm/yy'. I agree with Rob that the double keyword >solutions e.g. 'CENTxxxx' have a number of disadvantages. Also a whole >set of new e.g. ISO8601 formated data keywords may be too much. : : : If our first priority is indeed to "not to fool old FITS readers" then there is _no_ way to cope with DATE-OBS='31/12/99' because a two-figure year is inherently ambiguous once somebody starts writing data after 31/12/99 now that pre 1901 data has been archived as FITS. In this case the best you can do is to make sure no FITS reader can ever read in a year and then interpret it incorrectly. A solution I'm sure many people won't like is to strictly reserve the two-figure year format for the years 1900 to 1999, any other date being written 'DD/YY/XX' e.g. '01/01/XX'. You might call this the "fail-safe" solution since it provokes an error whenever there is some ambiguity over the date. I leave the argument over the required new keyword containing a four-figure year to others. - Pierre _-_-_ _-_-_ | Dr Pierre Maxted (pflm at star.maps.susx.ac.uk) | | | Astronomy Centre, University of Sussex | | | Falmer, Brighton, BN1 9QH | -_-_- Procrastinate now!!! -_-_- From owner-fitsbits at tarsier.cv.nrao.edu Sun Jun 30 14:21:39 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA05569; Sun, 30 Jun 1996 14:21:39 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id PAA01612; Sat, 29 Jun 1996 15:38:52 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id PAA16465 for ; Sat, 29 Jun 1996 15:38:48 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA25981; Sat, 29 Jun 96 15:38:46 EDT To: fitsbits at fits.cv.nrao.edu Date: 28 Jun 1996 18:52:15 GMT From: Pierre Maxted Message-Id: <4r19kv$d6f at infa.central.susx.ac.uk> Organization: Sussex University Astronomy Centre Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!inXS.uu.net!brighton.openmarket.com!decwrl!sunsite.doc.ic.ac.uk!susx.ac.uk!usenet Subject: MJD - not acceptable according to IAU (?) Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <4qroqt$7s4 at darkstar.UCSC.EDU>, Steve Allen wrote: >Take note, however, of the WCS draft paper at >http://fits.cv.nrao.edu/documents/wcs/wcs.html >which proposes to standardize the usage of MJD-OBS. This will work : : : ... which reminds me that at the last IAU general meeting there was some discussion of abondoning MJD since it was ambiguous/redundant. Am I correct? Is it feasible to drop MJD from the FITS standard? - Pierre -- _-_-_ _-_-_ | Dr Pierre Maxted (pflm at star.maps.susx.ac.uk) | | | Astronomy Centre, University of Sussex | | | Falmer, Brighton, BN1 9QH | -_-_- Procrastinate now!!! -_-_- From owner-fitsbits at tarsier.cv.nrao.edu Sun Jun 30 16:16:52 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id QAA05877; Sun, 30 Jun 1996 16:16:52 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id PAA05810; Sun, 30 Jun 1996 15:40:18 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id PAA25736 for ; Sun, 30 Jun 1996 15:40:04 -0400 (EDT) Received: from cfa.harvard.edu (cfa.harvard.edu [128.103.40.170]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id PAA08357 for ; Sun, 30 Jun 1996 15:40:00 -0400 (EDT) Received: from head-cfa (head-cfa.harvard.edu [128.103.42.3]) by cfa.harvard.edu (8.7.5/8.7.3) with SMTP id PAA00438 for ; Sun, 30 Jun 1996 15:38:45 -0400 (EDT) Received: from urania by head-cfa (SMI-8.6/SMI-SVR4) id PAA09637; Sun, 30 Jun 1996 15:38:44 -0400 Received: by urania (SMI-8.6/SMI-SVR4) id PAA09027; Sun, 30 Jun 1996 15:36:49 -0400 Date: Sun, 30 Jun 1996 15:36:49 -0400 From: jcm at urania.harvard.edu (Jonathan McDowell) Message-Id: <199606301936.PAA09027 at urania> To: fitsbits at fits.cv.nrao.edu Subject: DATE-OBS etc. Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk I am inclined to think we should go with the ISO date format, but I don't remember it and have a vague memory it had some not so nice features. Failing that, we should use the traditional astronomical most-significant order of yyyy-mm-dd; but since it is to be human readable I think separator characters like - or / are a good idea. I don't think DATE-ISO works because we actually need to replace DATE-END and DATE as well; let's replace the four letters DATE with something else, since that will give us a general solution. How about CALEN-OBS (or better yet CALEN_OBS since there has been discussion in the high energy community about it being a good idea to avoid - signs) for 'Calendar' which I think captures the idea that it's a human readable thing. I don't think the IAU MJD thing should worry us, as I understand it, it's not being forbidden, just not required in certain circumstances. Nevertheless, I personally think that in the long term we should use JD and not MJD, after all JD has several centuries of being a standard while MJD is still basically an informal convenience. But I suspect I'm in a minority on that issue. - Jonathan McDowell