From MAILER-DAEMON Tue Jun 1 19:32:52 1993 X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil X-VM-Bookmark: 25 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03992; Tue, 1 Jun 93 19:25:46 EDT Return-Path: Message-Id: Organization: W. M. Keck Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!agate!ames!news.Hawaii.Edu!hapuna!wlupton Reply-To: wlupton at keck.hawaii.edu (William Lupton) From: wlupton at keck.hawaii.edu (William Lupton) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Appropriate units for angular keywords Date: Tue, 1 Jun 1993 22:55:35 GMT I have been scanning the FITS literature for some definite guidance on the units to use for angular keywords. For example, should I write RA as floating point radians (as it is repres- ented internally), as an "hh:mm:ss.ss" character string, as floating point hours, or as floating point degrees? In any case, the FITS remark will show the value as "hh:mm:ss.ss". Similarly for Dec, Az, El and various offsets, where arc seconds is often a possibility (or seconds of time of course!). The FITS documents do refer to the IAU (1988) style guide and perhaps this contains some relevant recommendations (I haven't seen it). What do other people do? William Lupton PS, My personal feeling is that radians is in some sense "best" but that hours is going to be the most popular choice. Some will suggest degrees. From MAILER-DAEMON Tue Jun 1 20:14:33 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2260" "Tue" "1" "June" "1993" "20:02:38" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "50" "OGIP/93-001 (Vers 1993 May 21) - The specification of unit strings" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04011; Tue, 1 Jun 93 20:07:47 EDT Return-Path: Message-Id: <930601200238.20a008b6 at HEAGIP.GSFC.NASA.GOV> X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU" From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: OGIP/93-001 (Vers 1993 May 21) - The specification of unit strings Date: Tue, 1 Jun 1993 20:02:38 -0400 (EDT) OGIP/93-001 (Vers 1993 May 21) - The specification of unit strings "wlupton at keck.hawaii.edu (William Lupton)" writes (on a wide screen): > I have been scanning the FITS literature for some definite guidance > on the units to use for > angular keywords. For example, should I write RA as floating point > radians (as it is repres- > ented internally), as an "hh:mm:ss.ss" character string, as floating > point hours, or as > floating point degrees? In any case, the FITS remark will show the value > as "hh:mm:ss.ss". > Similarly for Dec, Az, El and various offsets, where arc seconds is often > a possibility (or > seconds of time of course!). I know it doesn't completely solve his dilemma, but he and few other subscribes may be interested to know that the HEASARC (High Energy Astrophysics Science Archive Research Center) here at NASA/GSFC has recently produced a new version of a memo (OGIP/93-001) which lists the "standard" strings to specify most (all ?) physical units within FITS files produced by the HEASARC (see below). The memo has been "round the High-Energy circuit" via the "heafits" e-mail exploder and I think fairly well recieved. The memo is heavily influenced on the IAU Style Guide (which I've just noticed we dont actually acknowledge), though naturally probably slightly biased towards X- & gamma-ray energies. Within the memo planar angles can be specified in radians, degrees, arcmins or arcsec (you'll have to read the memo to get the recommended strings :-). We purposely avoided making many recommendations since we thought up too many "ifs" and "buts", however it is clear that radians are the official (MKS) SI units, though most "users" seem to prefer degrees. Personally, I would suggest decimal (RA) hours be avoided, and strings never used for any keyword software may be interested in (I know the latter are trivial to parse and convert, but why both ?) Anyroad, should you be interested the OGIP/93-001 memo is available via anonymous ftp on legacy.gsfc.nasa.gov (128.183.8.233) as .caldb/docs/memos/ogip_93_001.tex the LaTeX source .caldb/docs/memos/ogip_93_001.ps PS version of complete doc. Constructive comments are welcomed. regards Ian M George (george at lheavx.gsfc.nasa.gov) HEASARC From fitsbits-request Tue Jun 1 22:42:34 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04436; Tue, 1 Jun 93 22:42:34 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells References: From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Appropriate units for angular keywords Date: Wed, 2 Jun 1993 03:42:21 GMT In article wlupton at keck.hawaii.edu (William Lupton) writes: WL> I have been scanning the FITS literature for some definite WL> guidance on the units to use for angular keywords. I recommend degrees, as specified in the 1981 Basic FITS paper. Degrees is the unit for the FITS WCS [World Coordinate System] conventions in use during the past decade. For example, headers of FITS files distributed from the IRAS (infrared) and Einstein (X-ray) satellites, and from all of ground-based radio astronomy, have used degrees, and they interoperate. The ground-based optical community should not re-invent this wheel. WL> For example, should I write RA as.. floating point degrees? Yes, use degrees. But it would be even better to supply CTYPEn, CRPIXn, CRVALn and CDn_m keywords, plus CDELTn and CROTAn for backwards compatibility, so that your data would be able to exploit the WCS capability of IRAF and AIPS and a number of other datasystems which support WCS. Using approximate values of these keywords would be better than supplying only RA and DEC. -*- Eric Greisen will present a poster paper on the proposed enhancement to FITS coordinate conventions at the AAS in Berkeley next week, and will also give a 10 minute talk on the subject during one of the WGAS sessions next Monday the 7th. If you haven't read the Greisen and Calabretta paper yet, I recommend that you do so. It is available via anonFTP at fits.cv.nrao.edu [192.33.115.8] in directory /fits/documents/wcs/ as files wcs.ps.*.Z. File wcs.ps.all.Z is the full document, in Postscript, with all of the figures. The figures are *beautiful*, so beautiful that they will give your Postscript printer an aerobic workout. You may also want to fetch files aips27.ps.Z and aips46.ps.Z in order to get a historic perspective on the FITS WCS conventions used for the past decade. -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Tue Jun 1 22:57:49 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04477; Tue, 1 Jun 93 22:57:49 EDT Return-Path: Message-Id: Organization: W. M. Keck Observatory Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!news.Hawaii.Edu!hapuna!wlupton References: Reply-To: wlupton at keck.hawaii.edu (William Lupton) From: wlupton at keck.hawaii.edu (William Lupton) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Appropriate units for angular keywords Date: Wed, 2 Jun 1993 02:37:07 GMT There; I narrowed the screen... I printed off the memo about OGIP FITS files mentioned by Ian George, but this is exclusively concerned with NAMES for units. In addition, Ian recommends: a) Not using hours. b) Never requiring character strings to be parsed. The trouble with not using hours is that times are crying out to be represented as hours. How am I to represent UT? My feeling is that radians is going too far, hours would be fine, but degrees would not be appreciated? If I am going to use hours for UT, I would rather use hours for RA, HA and ST! The trouble with never parsing character strings is that, for example, "FK5" (as a recommended value for RADECSYS) is surely better than 2, our internal representation for it (OK, the "FK5" bit would always be in the comment). We have quite a lot of things which are internally represented as enumerated types or bit-masks but my feeling is that they are better off as character strings in the FITS file. That way at least we can change the internal representation without meaning that all existing FITS files sudden- ly contain incorrect information. I know that in a sense these considerations are rather trivial but this is a chance to "do it right" and I am loathe to make arbitrary decisions which others may feel to be in conflict with common practice. William Lupton From fitsbits-request Thu Jun 3 12:02:50 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09739; Thu, 3 Jun 93 12:02:50 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: RESULT: WFC endorses BINTABLE/IMAGE/Blocking Date: Thu, 3 Jun 1993 17:01:59 GMT -=- WFC has approved the BINTABLE/IMAGE/Blocking proposals -=- Don Wells (WFC Chair) June 1, 1993 The WFC [WGAS FITS Committee] has voted unanimously, 20-0, to approve the BINTABLE, IMAGE and Blocking proposals which are currently being considered by the regional FITS committees for adoption as additions to the FITS standards. The WFC is the regional FITS committee for North America. WGAS is the Working Group for Astronomical Software of the American Astronomical Society. The voting membership of the WFC is representative of North American observational astronomy, both ground-based and space-based, at all observed frequencies. These three proposals were approved by the European FITS Committee [EFC] in April 1992, and the EFC reaffirmed their approval at their annual meeting in Garching in April 1993. The Japanese FITS Committee will vote on the proposals in the near future. If, as expected, they also approve them, the proposals will be considered by the IAU [International Astronomical Union] FITS Working Group, which controls the FITS standards. The Chairs of the FITS committees hope, and expect, that it will be possible to obtain IAU final approval of these proposals in time to have a FITS resolution passed by the General Assembly of the IAU at its triennial meeting at the Hague in August 1994. -=- Anonymous-FTP Information -=- Drafts of the three proposals are available at fits.cv.nrao.edu [192.33.115.8] in directory /fits/documents/proposals/ as the files 145877 May 18 16:29 bintable2.ps 38591 May 18 16:27 bintable2.tex 2183 Oct 1 1991 blocking90.txt 94980 Jun 4 1992 image.ps 12973 Mar 12 1992 image.tex Information about the current FITS standards is in the directory /fits/documents/standards/ as the files 7895 Oct 26 1992 fp89.txt 431252 Dec 29 1991 standard.ps 8325 Dec 29 1991 standard_read.ME 2710 Jan 24 1992 xtension.txt -=- The BINTABLE extension proposal -=- The 1979 Basic FITS Agreement specified an architecture for encoding an n-dimensional matrix with a self-documenting syntax. The 1979 design allowed for the possibility that arbitrary object types might be appended to the matrix. The FITS community has traditionally called such appended objects "extensions". The 1984 Generalized Extensions Agreement specified a set of meta-rules for the syntax of approved extension types. The first extension conforming to the Agreement was type TABLE, a self-describing syntax for tables in ASCII form which was also negotiated in 1984. The BINTABLE (BINary TABLE) extension is very similar to TABLE, but the data are encoded in binary rather than ASCII. In addition to the obvious advantages of compactness and processing efficiency, BINTABLE has a special superiority over TABLE: fields in the table are allowed to be *vectors*, not just scalars. This rule enables BINTABLE to encode sets of n-dimensional data matricies in the table. In fact, arrays of arbitrary *structures* can be encoded in BINTABLE, and can thereby gain the advantage of portability in a self-documenting form. The requirement to append extensions to the primary FITS matrix is not really a limitation on the use of TABLE and BINTABLE (and other extensions), because the rules of Basic FITS permit the primary matrix to have dimensionality zero. The prototype for BINTABLE was the experimental extension A3DTABLE, which was developed by Bill Cotton for the VLBA [Very Long Baseline Array] project in the mid-80s. The VLBA and the VLA [Very Large Array] had several years of production experience with A3DTABLE in the 80s. In the late 80s features were added, the wording of the draft document was refined, and the FITS committees agreed to use the name BINTABLE for this extension. Interoperability trials occurred circa 1989. More recently BINTABLE was selected as the interchange format for photon event data in the high energy astrophysics community. The committee votes on BINTABLE are acknowledging that BINTABLE is the de facto interchange and archive standard for a number of critical applications in astronomy. The FITS Committees consider the basic BINTABLE architecture to be the foundation for a variety of conventions to be negotiated in the future. For example, in 1991 Doug Tody and Bill Cotton proposed a simple trick that enables BINTABLE to encode variable length data structures in a backward compatible fashion (see Appendix A of the bintable2 document mentioned above for the details). More recently there has been extensive discussion of proposed conventions for encoding matricies in fields (Appendix B) and for arrays of character strings (Appendix C). All of these conventions will be layered on top of BINTABLE. Discussions of these ideas during the past three years has led to significant improvements in the BINTABLE draft. The committee votes on BINTABLE are acknowledging that BINTABLE now appears to be strong enough and flexible enough to support the layered conventions that astronomy will surely need in the future. -=- The IMAGE extension proposal -=- The IMAGE extension also conforms to the Generalized Extensions Agreement. It encodes an n-dimensional matrix. This extension is not intended to supercede the matrix capability of Basic FITS, but rather to augment it. IMACE enables datasystems to append things like PSFs and validity masks to matricies, thereby keeping the related objects together in one file. IMAGE was proposed by designers associated with the IUE [International Ultraviolet Explorer] satellite. -=- The proposed Blocking convention -=- FITS was described as a "tape" format in the original FITS papers, but it was redefined as a bitstream format in the 1984 Generalized Extensions Agreement. Blocking conventions must be negotiated for each new type of medium which may be used to convey FITS bitstreams in interchange. The 1990 Blocking proposal codifies de facto blocking conventions which have been in widespread use in the FITS community in recent years. -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Fri Jun 4 17:28:14 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["9554" "" "4" "June" "1993" "16:54" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "182" "FITS basics and informations (periodic posting)" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13074; Fri, 4 Jun 93 17:28:14 EDT Return-Path: Message-Id: <4JUN199316544035 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: FITS basics and informations (periodic posting) Date: 4 Jun 1993 16:54 EDT This basic FITS information is posted and updated periodically for the benefit of new readers and the reference of old readers. FITS (Flexible Image Transport System) is a data format designed to provide a means for convenient exchange of astronomical data between installations whose standard internal formats and hardware differ. A FITS file is composed of a sequence of Header Data Units (HDUs). The header consists of keyword=value statements, which describe the format and organization of the data in the HDU and may also provide additional information, for example, about the instrument or the history of the data. The data follow, structured as the header specifies. The data section of the HDU may contain a digital image, but, except for the first, *it doesn't have to*. Other possible formats include tables and multidimensional matrices that are not images. The first HDU must contain a multidimensional matrix or no data at all; the data in subsequent HDUs, called extensions, may be of any type, consistent with certain rules. The "Image" in the name comes from the original use of the format to transport digital images, but it's not just for images any more. FITS is not principally a graphics format designed for the transfer of pictures; it does not incorporate "FITS viewers", packages for decoding the data into an image. Users must develop or obtain separate software to convert the data from the FITS file into a form that can be readily displayed. As has been discussed in this newsgroup, and in alt.sci.astro.fits before it, the Extended Portable Bitmap Toolkit (pbm+) can be used for converting many FITS files to such a format. However, support is not guaranteed for all FITS files where the data are in the form of an image. In particular, there may be problems when the data matrix members are in IEEE floating point format (BITPIX<0) or the matrix has more than two dimensions (NAXIS>2). Archie Warnock and Ron Baalke have announced release of version 7.8 of the IMDISP program. IMDISP is an interactive image processing program that runs on an IBM PC computer and supports FITS input. IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov [128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp subdirectory. It is also available through Simtel-20 [192.88.110.20] at PD1:IMDISP78.ZIP. Additional discussion of FITS->image converters appears in this newsgroup from time to time. The fundamental references on FITS are the following four papers, often referred to collectively as the "Four FITS Papers". These papers are the formal standard for FITS, endorsed by the International Astronomical Union (IAU). Wells, D. C., Greisen, E. W., and Harten, R. H., "FITS: a flexible image transport system," Astronomy and Astrophysics Supplement Series, 44, 363-370, 1981. Greisen, E. W. and Harten, R. H., "An extension of FITS for small arrays of data," Astronomy and Astrophysics Supplement Series, 44, 371-374, 1981. (NOTE: The format described in this paper has been used almost exclusively to transport radio interferometry and is likely to be replaced by other formats in the future. Writing data other than radio interferometry data using this format is not recommended.) Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., "Generalized extensions and blocking factors for FITS," Astronomy and Astrophysics Supplement Series, 73, 359-364, 1988. Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., "The FITS tables extension, Astronomy and Astrophysics Supplement Series, 73, 365-372, 1988. A User's Guide for FITS, commissioned by NASA Headquarters, is maintained by the NASA/Science Office of Standards and Technology (NOST) FITS Support Office. This Guide is intended to be a tutorial for new FITS users. In addition to presenting the rules of FITS, it provides some of the history and reasoning behind the choice of the rules, adds recommendations on good practices, and discusses current developments in FITS. The current version, 3.0, was issued in January 1993. This document is at present available only in printed form, but steps are under way to generate a PostScript version that will work on many systems and a flat ASCII version. The NOST is sponsoring development of a formal standard for FITS. The goal is a document codifying FITS as endorsed by the IAU, eliminating some contradictions and ambiguities in the original FITS papers, that can be endorsed by the IAU FITS Working Group as the FITS standard. The document is being developed by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review by the astronomical community. Only minor revisions are expected to the draft currently available, version 0.3b, but the form of the standard is not final, and it does not supersede the four papers and Floating Point Agreement endorsed by the IAU as the official standard for FITS. The IAU has endorsed the Floating Point Agreement, which defines how floating point numbers are to be expressed in FITS. The basic agreement appears verbatim in the User's Guide, and the substance is incorporated in the Draft NOST FITS definition. The NOST maintains a file of FITS information available by anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in the directory FITS at this writing. A reorganization is planned that will move the FITS material to a FITS subdirectory under a STANDARDS directory. The FITS files include copies of the current NOST draft standard in flat ASCII, PostScript, and LaTeX. Style and index files are provided for the LaTeX form. Except that the ASCII form does not have an index, the copies in the three formats are identical; only one need be retrieved. A current list of the extension type (structure) names registered with the IAU FITS Working Group is maintained. Also available, in LaTeX form, is the text of the proposal for one of these new extension types, IMAGE. A modified version of this posting also appears there. An AAREADME.DOC file describes the contents of the directory. A SOFTWARE subdirectory contains a prototype for software that will eventually validate FITS files, along with instructions. The current versions investigates required keywords for primary headers and integer data arrays. There is also a copy of a program in C to read and list the headers of a FITS file and another file with information on publicly available FITS software packages. The ERRTEST subdirectory contains several versions of the same FITS file, a valid one and several with different kinds of header errors, for use in testing software to read FITS files. Be sure to use binary transfer for ftp access of FITS test files. Both the SOFTWARE and ERRTEST subdirectories include AAREADME.DOC files describing their content. A modified version of this posting is now in the main directory. Additional material can be obtained by anonymous ftp from the National Radio Astronomy Observatory, from fits.cv.nrao.edu, in the directory FITS. The Documents subdirectory (case is significant) contains copies of the BINTABLE Binary Tables extension proposal, which is now under consideration by the FITS committees, and a draft describing a proposed method for incorporating data compression under FITS. A number of additional documents are available in ASCII text form, including the proposal on physical blocking of FITS files on media other than tape, and material on FITS, its history, and the FITS community. Its FITS_wcs subdirectory contains material serving as the basis for continuing discussion of world coordinates issues, some of which appears on this newsgroup from time to time. One is a draft proposal for world coordinates conventions being developed by E. Greisen and M. Calabretta. Two AIPS memos describing projections from a sphere onto a plane are also included, in PostScript form. A copy of an earlier paper by D. Wells and R. Hanisch summarizing conclusions of a workshop on World Coordinates held in Charlottesville in 1988 remains in the Documents subdirectory. Unless otherwise noted, documents are available from NRAO in both LaTeX and PostScript forms. There is an AA.README file for the Documents subdirectory and a README file for its FITS_wcs subdirectory. Printed copies of many of the documents listed above can be obtained from the NOST Librarian. Printed copies of the User's Guide and either paper or electronic copies of the Draft NOST Standard, for those without ftp access, are available. Because of restrictions set by the copyright holder, NOST can send copies of the four FITS papers only to non-profit organizations. The NOST can be reached as follows: (Postal) NASA/Science Office of Standards and Technology Code 633.2 Goddard Space Flight Center Greenbelt MD 20771 USA (Internet) nost at nssdca.gsfc.nasa.gov (DECnet) NCF::NOST Telephone: +1-301-286-3575 8 a. m. - 5 p. m., U. S. Eastern Time If the Librarian is unavailable, a phone mail system takes the call after four rings. Please mention this posting in your request. Use the FITS office electronic mail address below for replies or questions. It is monitored by other NOST staff members when I am away from the office and provides a greater certainty of rapid response. Barry M. Schlesinger Coordinator, NASA/NSSDC NOST FITS Support Office +1-301-513-1634 fits at nssdca.gsfc.nasa.gov NCF::FITS From fitsbits-request Thu Jun 10 16:16:29 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4033" "" "10" "June" "1993" "15:54" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "95" "NOST Proposed FITS Standard vsn. 1.0 now available" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01658; Thu, 10 Jun 93 16:16:29 EDT Return-Path: Message-Id: <10JUN199315543905 at nssdca.gsfc.nasa.gov> Organization: NASA - Goddard Space Flight Center Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: NOST Proposed FITS Standard vsn. 1.0 now available Date: 10 Jun 1993 15:54 EDT The NASA/OSSA Office of Standards and Technology (NOST) technical panel has reached consensus on a Proposed Standard, the NOST Definition of the Flexible Image Transport System. This document is now being submitted to the NOST Accreditation Panel for approval as a NOST standard. It is also being submitted to the IAU FITS Working Group for endorsement as the international FITS standard. Until such time as the IAU FITS Working Group announces endorsement of the NOST standard, it will not supersede the existing FITS documentation as the international standard for FITS. The Proposed Standard, version 1.0, is now available electronically on the National Space Science Data Center computers and in printed form from the NOST librarian. It supersedes the Draft Standard, version 0.3. Copies are available in LaTeX, PostScript, and flat ASCII. The flat ASCII version does not have an index; otherwise, the versions in the different formats are identical. The NSSDCA computer is a VAX/VMS 9410; therefore, file names are case insensitive, and disks and subdirectories are designated as ANON_DIR:[FITS] for the disk "ANON_DIR" and the directory "FITS". Retrieve the AAREADME.DOC file first. It describes the files in the FITS directory and provides more detail on session and retrieval procedures. Internet (TCP/IP) DECnet ---------------------------------------------------------------------- Name: NSSDCA.GSFC.NASA.GOV NSSDCA Address: 128.183.36.23 15.188 (15548) ---------------------------------------------------------------------- =============================================================================== == DECnet AAREADME.DOC == =============================================================================== ndadsa $ copy/log nssdca::anon_dir:[fits]aareadme.doc * %COPY-S-COPIED, NSSDCA::ANON_DIR:[FITS]AAREADME.DOC;1 copied to DISKA":[MEV]AAREADME.DOC;2 (1 block) =============================================================================== == Anonymous FTP AAREADME.DOC copy via Internet == =============================================================================== ndadsa $ ftp nssdca.gsfc.nasa.gov NDADSA.GSFC.NASA.GOV MultiNet FTP user process 2.2(100) Connection opened (Assuming 8-bit connections) user anonymous cd fits get aareadme.doc;1 readme. quit Return-Path: Message-Id: <9306111921.AA03238 at fits.cv.nrao.edu> Resent-Sender: dwells at fits.CV.NRAO.EDU From: chaganti at ssl.DNET.NASA.GOV Sender: fitsbits-request at fits.CV.NRAO.EDU Resent-From: dwells (Don Wells) To: fitsbits at NRAO.EDU Subject: A would like to FITS capability in these areas. Date: Fri, 11 Jun 93 15:21:09 EDT Resent-Date: Fri, 11 Jun 93 15:21:09 EDT [This posting was sent to the request channel of "fitsbits" -Don] ------- Start of forwarded message ------- From: chaganti at ssl.DNET.NASA.GOV To: "fitsbits-request at fits.cv.nrao.edu" at EAST.DNET.NASA.GOV Subject: A would like to FITS capability in these areas. Date: Thu, 10 Jun 93 14:27:09 -0400 Hallo FITSir, I would like to know how FITS the following I gave the example for HDF APPlications HDF FITS Language Supported C,FORTRAN Inherent data Types char,short,long int,float,double, string User-defind types yes Dataconversion XDR,native Maximum array dimensions unlimited Extended array dimensions yes Hyperser access yes User-definable attributes yes Attribute types any Named dimensions yes Array-index ordering row,column sharabality yes Compression yes supporting tools many (X-window based, SGibased, etc) supporting machines sun,vax,mac,ibm,sgi,etc. Why should we use fits format for astonomy applications? (because it is accepted by international astronimacal union as standard or are there any other reasons) How about different machines portability? Please let me know any more information if you feel important about fits. etc. I appriciate your help? The reason for this survay is to find why this many data formats in use? Thanks in advance chaganti, kris - --------------- 4219-B, Myrtle wood dr. Email: DECNET : sslmor::chaganti HUNSVILLE, Internet: chaganti at xanth.msfc.nasa.gov AL 35816 chaganti at sslmor.msfc.nasa.gov - -------- ------- End of forwarded message ------- From fitsbits-request Fri Jun 11 16:46:48 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3817" "Fri" "11" "June" "1993" "21:46:30" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "83" "Re: A would like to FITS capability in these areas." "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03285; Fri, 11 Jun 93 16:46:48 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells References: <9306111921.AA03238 at fits.cv.nrao.edu> From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: A would like to FITS capability in these areas. Date: Fri, 11 Jun 1993 21:46:30 GMT In article <9306111921.AA03238 at fits.cv.nrao.edu> chaganti at ssl.DNET.NASA.GOV writes: I would like to [fill in this comparison of] FITS [with] HDF APPlications HDF FITS -- answers added: Language Supported C,FORTRAN N.A. <1> Inherent data Types char,short,long 8-bit unsigned, int,float,double, 16 and 32 2s complement string 32 and 64 IEEE FP more in BINTABLE <2> User-defind types yes yes, in BINTABLE <3> Dataconversion XDR,native N.A. Maximum array dimensions unlimited unlimited Extended array dimensions yes <---define this Hyperser access yes " " User-definable attributes yes " " Attribute types any " " Named dimensions yes " " Array-index ordering row,column first axis first sharabality yes <---define this Compression yes depends <4> supporting tools many (X-window based, SGibased, etc) <---yes supporting machines sun,vax,mac,ibm,sgi,etc. <---yes Why should we use fits format for astonomy applications? (because it is accepted by international astronimacal union as standard or are there any other reasons) FITS is the most effective format for interchanging data between astronomers separated in space and time (archiving is one-way interchange with the future) because astronomers everywhere have tools for manipulating FITS files. In addition, FITS is especially well adapted to astronomical needs. For example, it supports precise descriptions of world coordinate systems and tables. How about different machines portability? Of course. Please let me know any more information if you feel important about fits. etc. FITS is suitable for use in archives because it is self-describing (verbose ASCII headers) and because the specifications have been published in the professional astronomical journals where they will be readable centuries from now. HDF, by comparison, is a tagged binary structure design which depends on a (ephemeral) central authority to define and control the binary tag codes. -=- <1> FITS is a canonical *external* format used to interchange data between datasystems. The FITS format is *not* defined by a subroutine library, it is language independent. However, libraries do exist; e.g., the FITSIO library package from tetra.gsfc.nasa.gov is available in both C and Fortran bindings. <2> The BINTABLE extension (see /fits/documents/proposals/bintable2.* on fits.cv.nrao.edu) has codes for logical, bit array, string, complex, double complex and pointer types, in addition to the set supported by basic FITS. <3> The BINTABLE extension is effectively a self-describing syntax for arrays of arbitrary structs (user-defined types). A FITS file can contain an arbitrary number of BINTABLE extensions. <4> A considerable number of experiments have been done with compression of astronomical datasets. Some experiments have been done in the context of FITS (see /fits/documents/drafts/compress.* on fits.cv.nrao.edu, and also see the "compress" entry in the file /fits/wais-sources/nrao-fits.src). -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Mon Jun 14 18:11:45 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2749" "Mon" "14" "June" "1993" "23:11:20" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "63" "WFC Annual Report" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA11595; Mon, 14 Jun 93 18:11:45 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: WFC Annual Report Date: Mon, 14 Jun 1993 23:11:20 GMT On Monday June 7, in the annual business session of the WGAS [Working Group for Astronomical Software] at the summer meeting of the AAS in Berkeley, I delivered the report for 1993 in my role as Chair of the WGAS FITS Committee. I grouped items into four categories: meetings, communication tools, WGAS FITS Committee and work-in-progress. Here are the items that were on my single viewgraph: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=- Meetings -=- - NOST Data Formats Comparison Workshop, held June 92 at GSFC. Bob Hanisch and I (and Barry Schlesinger) represented astronomy. A report will appear eventually. - FITS BOF at ADASS'92, held November 92 in Boston. I perceived that a consensus for WCS development existed at this meeting. - FITS BOF at data handling workshop held April 93 at Trieste. -=- Communication Tools -=- - sci.astro.fits (fitsbits) has been effective in 92-93. In May 93 the newsgroup/exploder set a new traffic record, 163 KB. - HEAFITS exploder, activated March 93. -=- WGAS FITS Committee -=- - WFC voting membership was selected by Hanisch and Wells, is representative of North American observational astronomy, the committee officially formed in November 92. - formal voting process conducted on BINTABLE/IMAGE/Blocking, with two cycles of revisions to BINTABLE draft during Nov92-May93, final vote unanimous 20-0 on June 1, 93. The Japanese will vote soon, and then the IAU FITS Working Group will consider the proposals. I noted that the whole WGAS will never again vote on a FITS proposal. -=- Work-In-Progress -=- - fits.cv.nrao.edu anonymousFTP server reorganized somewhat in May93. WAIS server "nrao-fits" is now operational. - Greisen-Calabretta-?? WCS draft circulating. Astronomy needs this! - continuation of strings issue -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bob Hanisch, in his role as WGAS Chair, prefaced my FITS Committee report with remarks about the purpose, philosophy and evolution of FITS. The last item on my viewgraph (the string continuation issue) naturally stimulated a further discussion of FITS philosophy and strategy for our community. One person at the WGAS meeting expressed a worry that the expressive power (the flexibility) of the BINTABLE extension will lead to anarchy, a strategic loss of interoperability. -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Thu Jun 17 14:54:22 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3946" "Thu" "17" "June" "1993" "14:44:11" "-0400" "Usque ad mortem bibendum" "GEORGE at ROSGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "104" "OFSP Proposal for standard RA & dec keywords (v 93-Jun-17)" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03424; Thu, 17 Jun 93 14:54:22 EDT Return-Path: Message-Id: <930617144411.20e000bd at ROSGIP.GSFC.NASA.GOV> X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU" From: GEORGE at ROSGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: OFSP Proposal for standard RA & dec keywords (v 93-Jun-17) Date: Thu, 17 Jun 1993 14:44:11 -0400 (EDT) ------------------------------------------------------- | PROPOSED STANDARD KEYWORDS FOR THE SPECIFICATION | | OF RA & DEC WITHIN FITS FILES | ------------------------------------------------------- Version: 1993 June 17 At a meeting on 1993 Jun 16 of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review of the various keywords currently used to describe the RA,dec within FITS files. The OFSP found the current scheme (at least as often used within the High-Energy community) to be rather confusing, in some cases ambiguous, and insufficient to meet all the needs of the OGIP. After a review of many possible options, the OFSP therefore proposes & recommends the adoption & use of the (new) keywords listed below. Since this is an issue likely to be of interest to the general FITS community, the OFSP would welcome any comments (via FITSBITS) on this proposal. It should be noted that this proposal is restricted to FITS extensions containing data from a single 'pointing' (ie EXCLUDES extensions containing datasets from instruments capable of simultaneously observing in more than one direction, and from scanning experiments). Furthermore due to the pressures imposed by currently flying missions (ASCA, CGRO & ROSAT) there is an extremely urgent need for a convention for these keywords within the OGIP (& High-Energy community in general). The OFSP therefore plans to meet again in a couple of weeks to make its final recommendations. Thus FITBITS subscribers are urged to response with any comments etc on this timescale. THE PROPOSAL ************ 1) Reference Frame keywords --------------------------- The OFSP recommends both the following keywords are mandatory if one or more pairs of keywords specifying RA & dec (as defined in 2) are given. RADECSYS - a string denoting the stellar reference frame in use e.g. values: 'FK4','FK5' etc EQUINOX - a real giving the date of the equinox in decimal years (AD) e.g. values 2000.0, 1950.0 etc 2) The RA & dec coordinates --------------------------- In all cases listed below, the values of keywords are reals expressed in decimal DEGREES. Obviously only those keyword pairs considered necessary need be specified. However, the values of ALL such keyword pairs MUST be given in the same reference frame as specified by the values of the RADECSYS & EQUINOX keywords (see 1). a) The Positions of astronomical objects/sources The OFSP recommends the position of a source is given using the keywords: RA_OBJ DEC_OBJ b) The Pointing Direction of the Instrument. The OFSP recommends the pointing direction of the instrument is given using the keywords: RA_PNT DEC_PNT where, - in the case of imaging instruments, the values of these keywords give the direction of the optical axis of the instrument (after all borsighting corrections etc have been applied). - in the case of non-imaging instrumentation, the values of these keywords give the direction of some other (instrument-specific) vector. It is anticipated that in most cases this will be the direction of maximum instrument sensitivity. For instruments with <100% stable pointing accuracy, the above pair of keywords should be the mean values during the observation. c) The orientation of the Spacecraft The OFSP recommends the orientation of the spacecraft (or telescope platform) is given by the specification of any/all of the following keyword pairs: RA_SCX DEC_SCX RA_SCY DEC_SCY RA_SCZ DEC_SCZ giving the orientation of the spacecraft X-, Y- & Z-axes respectively. For instruments with <100% stable pointing accuracy, the above pairs of keywords should be the mean values during the observation. ----------------------------------- END ---------------------------------- Ian M George NASA/GSFC OFSP 1993 Jun 17 From fitsbits-request Thu Jun 17 16:39:49 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3194" "Thu" "17" "June" "1993" "21:39:34" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "85" "Server \"nrao-fits\" now in WAIS-Directory-of-Servers" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03559; Thu, 17 Jun 93 16:39:49 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Server "nrao-fits" now in WAIS-Directory-of-Servers Date: Thu, 17 Jun 1993 21:39:34 GMT (:source :version 3 :ip-address "192.33.115.8" :ip-name "fits.cv.nrao.edu" :tcp-port 210 :database-name "nrao-fits" :cost 0.00 :cost-unit :free :maintainer "dwells at fits.cv.nrao.edu" :description "Server created with WAIS release 8 b5 on Jun 15 21:51:49 1993 by dwells at fits.cv.nrao.edu WAIS Server for FITS Documents Host fits.cv.nrao.edu [192.33.115.8] supports an anonymous-FTP archive for the Flexible Image Transport System [FITS], the standard data interchange and archival format of the worldwide astronomy community. The archive includes a variety of documents in directory /fits/documents, discussions of FITS support for various operating systems in directory /fits/os-support, binary test files in directories /fits/sampledata and /fits/testfiles, and FITS-related newsgroup and exploder traffic in the directory /fits/traffic. Fits.cv.nrao.edu also supports a WAIS server which indexes all of the text files in the archive, including those coded in Postscript. I tabulate some sample WAIS searches below; the best documents returned by these keys can be used to refine the WAIS searches using relevance feedback. Key(s) Fetches: --------------- ------------------------------------------------------ standard FITS standards documents (the NASA FITS standard is the first document returned). ron cdc Discussions of the early history of FITS, of pre-FITS prototyping, of the FITS 'birthday' and of 'icunabula'. nost support Documents produced by the FITS Support Office at the NOST [NASA/OSSA Office of Standards and Technology] at Goddard Space Flight Center [GSFC]. european Reports of activities of the European FITS Committee and Annual Reports of the Chair of the IAU FITS WG. ieee IEEE floating point numbers in FITS files, standards and discussions of usage, expecially for VAXen. bintable Documents and traffic related to the BINTABLE (Binary Table) FITS extension type. exabyte Discussions of blocking and tapemarks on exabytes and other cartridge tapes, and of FITS blocking conventions. wcs World Coordinate Systems -- documents discussing the semantics of describing various projective geometries using FITS header syntax. ogip Documents related to the NASA HEASARC OGIP conventions for using the FITS BINTABLE extension to interchange and archive high energy astrophysics data. dish spectra Discussions of use of FITS to encode sets of spectra, especially for single-dish radio telescopes. units Discussions of physical units usage (e.g. SI vs. cgs). continuation A May-1993 discussion of how to represent character strings longer than 68 characters in FITS headers. mac macos Discussions of FITS support for Macintosh systems. skipped Listings of headers of FITS sampledata and testfiles. compress Discussions of use of data compression in astronomy, especially in the FITS context. " ) -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Thu Jun 17 18:23:50 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3724" "Thu" "17" "June" "1993" "17:37:49" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "78" "OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords (v 93-Jun-17)" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03819; Thu, 17 Jun 93 18:23:50 EDT Return-Path: Message-Id: <930617173750.20a00204 at HEAGIP.GSFC.NASA.GOV> X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU" From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords (v 93-Jun-17) Date: Thu, 17 Jun 1993 17:37:49 -0400 (EDT) ------------------------------------------------------- | THE USE OF THE EXTNAME KEYWORD AND THE PROPOSED | | INTRODUCTION OF TWO NEW KEYWORDS | ------------------------------------------------------- Version: 1993 June 17 At a meeting on 1993 Jun 16 of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review of the use of the EXTNAME keyword within the OGIP. The OFSP found that it was common practice within the OGIP to use the value of the EXTNAME keyword to simultaneously describe both the generic *kind* of dataset being stored, and additional *details* of the dataset. Thus values of the EXTNAME keyword were being formed by the concatination of 2 or more sub-strings. This gives rise to long, and often user-unfriendly, EXTNAMEs essentially containing a variety of different pieces of information. More importantly these strings are apparently incompatible with a number of IRAF tasks. An example is: EXTNAME = 'GTI_STANDARD' meaning the dataset is a list of all 'standard' "Good Time Intervals". An (admittedly extreme) example is: EXTNAME = 'SGL_SPEC_STAT_+UNC' meaning the dataset contains the positive statistical uncertainties on a single spectrum. Whilst such use of EXTNAME keyword is legal FITS, the OFSP proposes & recommends the adoption/use of the two keywords listed below. Since this is an issue likely to be of interest to the general FITS community, the OFSP would welcome any comments (via FITSBITS) on this proposal. Furthermore due to the pressures imposed by currently flying missions (ASCA, CGRO & ROSAT) there is an extremely urgent need for a convention for these keywords within the OGIP (& High-Energy community in general). The OFSP therefore plans to meet again in a couple of weeks to make its final recommendations. Thus BITFITS subscribers are urged to response with any comments etc on this timescale. THE PROPOSAL ************ The OFSP recommends the use of the EXTNAME keyword be changed (at least within the OGIP), and that two new keywords, EXTCLASS & EXTTYPE be introduced: EXTNAME - Can be any string & is essentially not used by OGIP s/w (NOTE: IRAF can only cope with 6 character strings) EXTCLASS - Is a new string describing the sort of dataset stored (see below) EXTTYPE - Is a new string available to give more specific details on exactly what type of data is stored (see below) A few examples should make the distinctions between the keywords more obvious: 1) For various "Good Time Intervals" EXTNAME = 'ABCBEF' (or whatever you like) EXTCLASS = 'GTI' (some sort of GTI is stored) EXTTYPE = 'STANDARD' (the GTIs from standard processing are stored) or EXTTYPE = 'ALL' (all times when the instrument is on are stored [no filtering has been applied]) or EXTTYPE = 'UNKNOWN' (uncertain what is stored) 2) For various "Events" lists EXTNAME = 'GHIJKL' (or whatever you like) EXTCLASS = 'EVENTS' (some sort of EVENTS list is stored) EXTTYPE = 'GOOD' (accepted events [only] are stored) or EXTTYPE = 'BAD' (rejected events [only] are stored) or EXTTYPE = 'ALL' (all events [no filtering] are stored) or EXTTYPE = 'UNKNOWN' (uncertain what events are stored) The two new keywords follow a logical hierachy, solve all the current problems, and seem general enough to give us (the OGIP, and general FITS community) flexibility in the future. ----------------------------------- END ---------------------------------- Ian M George NASA/GSFC OFSP 1993 Jun 17 From fitsbits-request Thu Jun 17 19:16:30 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2201" "Thu" "17" "June" "93" "19:15:28" "EDT" "Maureen Conroy" "mo at cfa234.harvard.edu " nil "49" "Comments on OGIP proposal for EXTNAME keywords" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04138; Thu, 17 Jun 93 19:16:30 EDT Return-Path: Message-Id: <9306172315.AA11477 at cfa234.harvard.edu> From: mo at cfa234.harvard.edu (Maureen Conroy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at NRAO.EDU Subject: Comments on OGIP proposal for EXTNAME keywords Date: Thu, 17 Jun 93 19:15:28 EDT Comments on the OGIP proposal for EXTNAME keywords First, let me correct the statement that IRAF can only handle 6 character keyword values. This is NOT correct, though it is recommended in the FITS standards, due to limitations on many systems, that KEYWORD values be UNIQUE in the first 8 characters. For ROSAT FITS, I had recommended a guideline of 6 because most of our previously used extensions were 3 characters, and then combinations would naturally be 6 characters. Also, in PROS, these keywords are then used as suffixes on the DATASET name to produce the final unique filenames; keeping all these as short as possible seems best for the user. An easy way to provide automatic filenaming for FITS readers is to name the file according to the EXTNAME. The FITS proposal for BINTABLE encourages this, and suggests that EXTNAME can be used to give a name to the extension file to distinguish it from similar files. This of course doesn't work, if there is more than 1 extension with the same EXTNAME in a file. Also with this in mind, I prefer EXTNAMEs that do not contain blanks. Personally, I am concerned by the recent proliferation of proposed keywords. I would prefer to see these issues handled within the existing definitions. I think it would be more flexible to make separate FITS files for the different CLASSES and TYPES that are discussed in this proposal. Then simple HISTORY or COMMENT keywords would be sufficient to record the processing history or derivation of the data sets. This has the additional advantage that users and/or readers don't have to wade through long lists of events, in which they may not be interested, to get to the list of choice. In this way, one can have for the current HEA EVENT lists: a) STANDARD event list FITS file containing extensions EVENTS GTI TSI QLIM etc... b) REJECTED event list FITS file containing extensions EVENTS GTI ... c) ALL ( or unscreened ) event list FITS file containing extensions EVENTS GTI ... FITS readers have no need to know the processing history of these files. The user can choose which sets of processed data are to be read. Maureen Conroy ROSAT/PROS group at SAO From fitsbits-request Thu Jun 17 19:18:00 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2229" "Thu" "17" "June" "93" "19:17:16" "EDT" "Maureen Conroy" "mo at cfa234.harvard.edu " nil "46" "Comments on OGIP on proposal for RA/Dec keywords" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04147; Thu, 17 Jun 93 19:18:00 EDT Return-Path: Message-Id: <9306172317.AA11490 at cfa234.harvard.edu> From: mo at cfa234.harvard.edu (Maureen Conroy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at NRAO.EDU Subject: Comments on OGIP on proposal for RA/Dec keywords Date: Thu, 17 Jun 93 19:17:16 EDT Comments on the OGIP RA/DEC keyword proposal It seems to me that most of the information that the OGIP is trying to record in FITS has already been provided by, or can be derived from, the World Coordinate System (WCS) keywords. Furthermore, WCS provides for a large number of coordinate systems and is not restricted to RA and Dec. Using keywords which REQUIRE RA and Dec lacks generality. 1) Reference Frame Keywords The current WCS definition has keywords to describe the type of coordinate system: CTYPE1 CTYPE2 which allows the definition of a wide range of coordinate systems not restricted to RA and Dec. Even RA and Dec are not sufficent to describe a position in a field without specifying the projection geometry assumed. Why not use what WCS has already provided? The HEAFITS has devised KEYWORDS to define WCS-style information for FITS TABLE extensions, that are analagous to the available IMAGE KEYWORDS. 2) RA & Dec coordinates b) The POINTING direction of the instrument, which you define to be the direction of the OPTICAL AXIS, should be derivable from the WCS CD-matrix. For ROSAT, the coordinates of the OPTICAL axis are recorded as the reference points of the DETECTOR coordinate axes. Perhaps, all that is needed is a keyword to define the OPTICAL AXIS pixel coordinates. A WCS matrix provides the necessary information to convert any pixel position to World Coordinates (RA and Dec or whatever coordinate system is defined). This, of course, only works if the pointing is stable. If the pointing is NOT stable, we have never found an 'average' optical axis to be of much use. And then there is the problem of defining mean - is it time-weighted, etc. c) The Spacecraft Orientation Again, if the pointing is stable, isn't the spacecraft orientation defined by the WCS CD-matrix? If it isn't stable, what I would call the 'average aspect solution', seems to be of no particular use and has the above mentioned problem of how the 'mean' is weighted, etc. For ROSAT where the pointing is intentionally NOT stable, a complete set of 'aspect' records giving the spacecraft orientation each second is saved as part of the archived data. Maureen Conroy ROSAT/PROS group at SAO From fitsbits-request Thu Jun 17 22:56:21 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1195" "Fri" "18" "June" "1993" "02:17:32" "GMT" "Greg Hennessy" "gsh7w at fermi.clas.Virginia.EDU " nil "28" "Re: Server \"nrao-fits\" now in WAIS-Directory-of-Servers" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04235; Thu, 17 Jun 93 22:56:21 EDT Return-Path: Message-Id: Organization: University of Virginia Path: cv3.cv.nrao.edu!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gsh7w References: From: gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Date: Fri, 18 Jun 1993 02:17:32 GMT Don Wells writes: # WAIS Server for FITS Documents #Host fits.cv.nrao.edu [192.33.115.8] supports an anonymous-FTP archive #for the Flexible Image Transport System [FITS], the standard data #interchange and archival format of the worldwide astronomy community. Thanks Don. I note that there are several postscript files. I did a quick and dirty hack to kludge a ~/bin/wais-ps-display file to invoke ghostscript on these, and it almost sorta worked, but it quickly scrolled by faster than could read. I could move to a slower workstation, but was wondering if anyone knew a way to have ghostscript wait for a carriage return to move to the nextpage. Don, I also note that you only catalog the text files, and I know that there are lots of fits images floating on your machine, esp on the CD-rom system you have. What are your thought of putting these available through wais, so people can invoke saoimage on these files? Or would it be too much bandwidth for the machine, and network, to handle? Greg -- -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w at virginia.edu UUCP: ...!uunet!virginia!gsh7w From fitsbits-request Thu Jun 17 23:24:55 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["773" "Fri" "18" "June" "1993" "03:02:20" "GMT" "Marc Andreessen" "marca at ncsa.uiuc.edu " nil "21" "Re: Server \"nrao-fits\" now in WAIS-Directory-of-Servers" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04271; Thu, 17 Jun 93 23:24:55 EDT Return-Path: Message-Id: Organization: Nat'l Center for Supercomputing Applications Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!ux1.cso.uiuc.edu!news.cso.uiuc.edu!128.174.5.61!marca References: From: marca at ncsa.uiuc.edu (Marc Andreessen) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Date: Fri, 18 Jun 1993 03:02:20 GMT In article gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) writes: I note that there are several postscript files. I did a quick and dirty hack to kludge a ~/bin/wais-ps-display file to invoke ghostscript on these, and it almost sorta worked, but it quickly scrolled by faster than could read. I could move to a slower workstation, but was wondering if anyone knew a way to have ghostscript wait for a carriage return to move to the nextpage. Use the 'ghostview' front-end for ghostscript, which provides a fairly nice user interface, including full page control. prep.ai.mit.edu in /pub/gnu... Marc -- Marc Andreessen Software Development Group National Center for Supercomputing Applications marca at ncsa.uiuc.edu From fitsbits-request Fri Jun 18 03:57:52 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2793" "Fri" "18" "June" "1993" "09:43:01" "+0200" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "56" "Re: OFSP Proposal for standard RA & dec keywords (v 93-Jun-17)" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04383; Fri, 18 Jun 93 03:57:52 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative In-Reply-To: <930617144411.20e000bd at ROSGIP.GSFC.NASA.GOV> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Cc: heafits at legacy.gsfc.nasa.gov Subject: Re: OFSP Proposal for standard RA & dec keywords (v 93-Jun-17) Date: Fri, 18 Jun 1993 09:43:01 +0200 (MET DST) On Thu, 17 Jun 1993 GEORGE at ROSGIP.GSFC.NASA.GOV wrote: > ------------------------------------------------------- > | PROPOSED STANDARD KEYWORDS FOR THE SPECIFICATION | > | OF RA & DEC WITHIN FITS FILES | > ------------------------------------------------------- > Version: 1993 June 17 My general feeling is that it is a very reasonable proposal, in the framework of high energy missions at least. > > a) The Positions of astronomical objects/sources > b) The Pointing Direction of the Instrument. > c) The orientation of the Spacecraft I agree with the above list of items, which is more or less what I was using in the past (non-FITS) for the description of a pointing. Misalignments etc. should in principle be accounted for as "calibration" data. However I wonder if there are any relationships or interferences between things like a misalignment matrix and the WCS stuff. I do not have time to look into the matter, but I would appreciate knowing if anybody has done / will do a more detailed analysis of this. I still expect that each mission will need to do its own bits of trigonometry etc. to do things like computing collimator transmissions or vignetting or whatever. But it is much better to describe those mission-specific calculation using a common nomenclature, which is what is proposed here, therefore I support it. > 2) The RA & dec coordinates > In all cases listed below, the values of keywords are reals expressed > in decimal DEGREES. Obviously only those keyword pairs considered necessary > That's fine for me. However I remember there was some discussion in the past about preferring radians to degrees. How did that go ? > RA_OBJ > DEC_OBJ You mean the target here, don't you ? I.e. the object named in the OBJECT keyword. If yes OK for me. (if there are many interesting objects in the FOV one might think to RA_OBJ1, RA_OBJ2 etc. but I am personally not enthusiastic with number-indexed keywords unless REALLY necessary) ----------------------------------------------------------------------------- A member of G.ASS : Group for Astronomical Software Support ----------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR Milano | U N I C U I Q U E via Bassini 15 - I-20133 Milano - Italy | System Manager Internet: LUCIO at IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: | ----------------------------------------------------------------------------- From fitsbits-request Fri Jun 18 04:29:54 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2847" "Fri" "18" "June" "1993" "10:12:10" "+0200" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "59" "Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords (v 93-Jun-17)" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04408; Fri, 18 Jun 93 04:29:54 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative In-Reply-To: <930617173750.20a00204 at HEAGIP.GSFC.NASA.GOV> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Lucio Chiappetti Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Cc: heafits at legacy.gsfc.nasa.gov Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords (v 93-Jun-17) Date: Fri, 18 Jun 1993 10:12:10 +0200 (MET DST) On Thu, 17 Jun 1993 GEORGE at HEAGIP.GSFC.NASA.GOV wrote: > ------------------------------------------------------- > | THE USE OF THE EXTNAME KEYWORD AND THE PROPOSED | > | INTRODUCTION OF TWO NEW KEYWORDS | > ------------------------------------------------------- > Version: 1993 June 17 > > The OFSP recommends the use of the EXTNAME keyword be changed (at least > within the OGIP), and that two new keywords, EXTCLASS & EXTTYPE be > introduced: > > EXTNAME - Can be any string & is essentially not used by OGIP s/w > EXTCLASS - Is a new string describing the sort of dataset stored (see below) > EXTTYPE - Is a new string available to give more specific details on > exactly what type of data is stored (see below) > I am really perplexed by this proposal, and I fail to see a clear distinction between what is used for inter-package data exchange (i.e. to make the file readable, or at least understandable to a "foreign" package) and what is used exclusively within a GIVEN package. My approach would be to use EXTNAME to classify in a broad sense the kind of file. In particular in the high energy astrophysics context the "kinds of files" I am using are : 'SPECTRUM' count/s (or photon/s) spectra 'RATE' time profile (anything vs time) 'PHOTON LIST' list of photons or events in addition to these I consider images and response matrices (but in my view they are images, not bintables, therefore do not use EXTNAME) If each one of those supports variations, these are either in the form (e.g. number and names of columns; and therefore are self-docu- mented by other standard keywords like TTYPEn TFORMn etc.), or are in the semantics (which is relevant within a particular package only, and can be described by whatever optional keyword). Being my primary interest in the possibility of EXCHANGING data (i.e. importing/exporting them from/to my own package to/from other packages) I would as far as possible avoid the use of "specialized" convention, which may force to have a dedicated conversion utility for each package, instead of a generic reader. As a conclusion, I do not see why you cannot use EXTNAME (instead of EXTCLASS) for the top-level classification (to be kept to a FEW classes, essentially the ones I listed above ... the exact names can be agreed if you are concerned with imbedded blanks, or more than 6 or 8 characters), and whatever YOU like for the bottom level classification. Still, I perceive that the top-level classification (EXTNAME) is of relevance within the X-ray (HEAFITS) community (but not necessarily within a larger - fitsbits - community), while the lower level classification is only "private" to your software. From fitsbits-request Fri Jun 18 09:37:07 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4083" "Fri" "18" "June" "1993" "14:36:51" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "76" "Re: Server \"nrao-fits\" now in WAIS-Directory-of-Servers" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06156; Fri, 18 Jun 93 09:37:07 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells References: From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Date: Fri, 18 Jun 1993 14:36:51 GMT In article gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) writes: Don Wells writes: # WAIS Server for FITS Documents GH> Thanks Don. You are welcome, Greg. The person you should really thank is Archie Warnock. He has pioneered and advocated the WAIS technology in astronomical applications as a part of the STELAR project at NASA. He has assisted me in several ways; e.g. the executables of my server and indexer were linked by him. Archie has established a directory of astronomy-related WAIS servers on host hypatia.gsfc.nasa.gov, and I recommend that copies of new astronomy-related WAIS source files be sent to him. Mine was included in the NASA directory two weeks before I registered it at the master directory at think.com. GH> I note that there are several postscript files. I did a quick and GH> dirty hack.. to invoke ghostscript on these.. it almost.. worked.. Wonderful! I asked Archie about the Postscript files when I was developing my server, and he recommended that I include them to permit the kind of experimentation which you have done. GH> .. I.. note that you only catalog the text files.. there are lots GH> of FITS images.. on your machine.. What are your thought of GH> [making] these available through WAIS, so people can invoke GH> saoimage on these files?.. I could certainly command the waisindex program to include the names of the binary files in the index, but I am unsure how to tag them as type "FITS" so that your client could invoke the appropriate display tool; WAIS has a rich set of object types, but the set doesn't (yet) include FITS. In my opinion the appropriate technology for this application is not WAIS but WWW, the World-Wide-Web. Most people know the Web through the name of its most sophisticated client implementation, xmosaic from NCSA at UIUC. WAIS is an excellent means for discovering relevant *text* documents using keywords, and fetching those documents; WAIS is less well suited for dealing with non-textual material. WWW is an excellent means for using hypertext links in text documents to point at objects of arbitrary type. The links (called URLs [Universal Resource Locators] in WWW jargon) can code the object type, and many existing examples of WWW documents include pointers to digital image files in various formats. I expect that it will be easy to get object type "FITS" registered in the WWW community. It appears to me that WAIS and WWW are complementary. The biggest problem in using the Web is finding the hypertext page that points to the resources you want. Once you find the first page it is easy to find more relevant pages and to invoke arbitrary processes to do arbitrary things to arbitrary objects. Finding things in text (like home pages) is what WAIS does best! The xmosaic WWW client already talks to WAIS servers as well as WWW servers, and and so it appears to me that it should be straight-forward for the WWW community to create a symbiotic relationship between the two protocols. I am watching the WWW technology closely, and I expect that before the end of 1993 I will activate a Web server on fits.cv.nrao.edu, with the "home page" being the master READ.ME file of the existing anonymous FTP server. Anyone who finds my anonFTP server using WAIS or Archie, and who is also an xmosaic (WWW) user, will spot the URLs appearing in the document(s), and will copy them into their own documents and "hot lists", and soon the world-wide Web will have many pointers to my Web server. This is an exciting time for people who care about the classical resource discovery problem --- practical solutions (Archie, Gopher, WAIS, WWW) are already in hand, and the further development and integration of these solutions is making rapid progress. -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From dwells Fri Jun 18 09:49:26 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["457" "Fri" "18" "June" "1993" "9:47:08" "-0400" "CORCORAN at ndadsa.gsfc.nasa.gov" "CORCORAN at ndadsa.gsfc.nasa.gov" nil "13" "re:OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06201; Fri, 18 Jun 93 09:49:26 EDT Resent-Message-Id: <9306181349.AA06201 at fits.cv.nrao.edu> Return-Path: Message-Id: <9306181349.AA06195 at fits.cv.nrao.edu> Resent-Sender: dwells From: CORCORAN at ndadsa.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU Resent-From: dwells (Don Wells) To: fitsbits Subject: re:OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE Date: Fri, 18 Jun 1993 9:47:08 -0400 (EDT) Resent-Date: Fri, 18 Jun 1993 9:47:08 -0400 (EDT) ------- Start of forwarded message ------- Message-Id: <930618094708.22800397 at ndadsa.gsfc.nasa.gov> From: CORCORAN at ndadsa.gsfc.nasa.gov To: fitsbits-request at fits.CV.NRAO.EDU Subject: re:OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE Date: Fri, 18 Jun 1993 9:47:08 -0400 (EDT) In my last post, EXTTYPE = 'EVENTS' should read EXTCLASS = 'EVENTS'. Sorry about that Ian. Mike Corcoran ROSAT/OGIP FITS group ------- End of forwarded message ------- From dwells Fri Jun 18 09:50:07 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4941" "Fri" "18" "June" "93" "09:50:05" "EDT" "CORCORAN at ndadsa.gsfc.nasa.gov" "CORCORAN at ndadsa.gsfc.nasa.gov" nil "97" "Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06213; Fri, 18 Jun 93 09:50:07 EDT Resent-Message-Id: <9306181350.AA06213 at fits.cv.nrao.edu> Return-Path: Message-Id: <9306181350.AA06207 at fits.cv.nrao.edu> Resent-Sender: dwells From: CORCORAN at ndadsa.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU Resent-From: dwells (Don Wells) To: fitsbits Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords Date: Fri, 18 Jun 93 09:50:05 EDT Resent-Date: Fri, 18 Jun 93 09:50:05 EDT [This message was sent to "fitsbits-request" rather than to "fitsbits". -Don] ------- Start of forwarded message ------- Message-Id: <930618094224.22800397 at ndadsa.gsfc.nasa.gov> From: CORCORAN at ndadsa.gsfc.nasa.gov To: fitsbits-request at fits.CV.NRAO.EDU Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords Date: Fri, 18 Jun 1993 9:42:24 -0400 (EDT) Maureen Conroy at CFA writes: >First, let me correct the statement that IRAF can only handle >6 character keyword values. This is NOT correct, though >it is recommended in the FITS standards, due to limitations on >many systems, that KEYWORD values be UNIQUE in the first 8 characters. >For ROSAT FITS, I had recommended a guideline of 6 because most of >our previously used extensions were 3 characters, and then combinations >would naturally be 6 characters. Also, in PROS, these keywords are then >used as suffixes on the DATASET name to produce the final unique >filenames; keeping all these as short as possible seems best for the user. Sorry Maureen, I think I'm responsible for this nasty rumor. But at present for ROSAT FITS, as you point out, it is a requirement that EXTNAMEs be restricted to 6 characters, without blanks. >An easy way to provide automatic filenaming for FITS readers is to >name the file according to the EXTNAME. The FITS proposal >for BINTABLE encourages this, and suggests that EXTNAME can be used >to give a name to the extension file to distinguish it from similar files. >This of course doesn't work, if there is more than 1 extension with the >same EXTNAME in a file. Also with this in mind, I prefer EXTNAMEs >that do not contain blanks. Since some groups are using the EXTNAME to construct names for files, it seems to me that use of blanks in EXTNAMES should be STRONGLY discouraged. In addition, the uniqueness issue argues against using EXTNAME to describe the "type" of file, hence the need for the EXTTYPE, etc., set of keywords. > Personally, I am concerned by the recent proliferation of proposed >keywords. I would prefer to see these issues handled >within the existing definitions. I think it would be >more flexible to make separate FITS files for the different CLASSES and >TYPES that are discussed in this proposal. Then simple HISTORY or >COMMENT keywords would be sufficient to record the processing history >or derivation of the data sets. This has the additional advantage >that users and/or readers don't have to wade through long lists of >events, in which they may not be interested, to get to the list of >choice. I wholeheartedly that existing keywords/structures should be used whenever appropriate. But I still think there is a need for a keyword in the header which documents the "type" of extension the user is dealing with, and I DON'T think that the EXTNAME keyword fills the bill. > In this way, one can have for the current HEA EVENT lists: > a) STANDARD event list FITS file containing extensions > EVENTS > GTI > TSI > QLIM > etc... > b) REJECTED event list FITS file containing extensions > EVENTS > GTI > ... > c) ALL ( or unscreened ) event list FITS file containing extensions > EVENTS > GTI > ... >FITS readers have no need to know the processing history of these files. >The user can choose which sets of processed data are to be read. As you are aware (but probably most aren't) the ROSAT FITS files will include the STANDARD events (i.e. those that have been accepted by standard processing) and the REJECTED events (i.e. "bad" photons as determined by standard processing) as separate extensions in the SAME file. In such a case the EXTTYPE = 'EVENTS' keyword is very useful to tell the user that the file is an EVENT-type file. The EXTNAMES for the 2 extensions are different (STDEVT and REJEVT) which allows PROS to construct tables having different names. If we used EXTNAME = 'EVENTS' for both tables (as originally suggested) then the PROS-constructed name for each table would be the same. I think the same problem would occur if the standard and rejected photons were put in separate files, given that PROS (as I understand it) constructs the table name by basically appending the EXTNAME to the sequence number (which is preceeded by rp, rh or rf for US data). For example, suppose we had the rejected photons in a file rp123456_rej.fits with an EXTNAME = 'EVENTS' and the accepted photons in a separate file rp123456_std.fits (also with EXTNAME = 'EVENTS'). My understanding is that for each case pros would generate a photon events list table called rp123456_events.tab, which I think would be confusing to the user. Using different EXTNAMES gets around this problem, but at the same time it means that you CANNOT use EXTNAME to designate the generic "type" of the file (which is the same for both extensions) thus the need for EXTTYPE, EXTCLASS, etc. Mike Corcoran ROSAT/OGIP FITS group ------- End of forwarded message ------- From fitsbits-request Fri Jun 18 10:33:47 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4011" "Fri" "18" "June" "1993" "10:33:32" "-0400" "CORCORAN at ndadsa.gsfc.nasa.gov" "CORCORAN at ndadsa.gsfc.nasa.gov" nil "79" "Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06294; Fri, 18 Jun 93 10:33:47 EDT Return-Path: Message-Id: <930618103332.22800397 at ndadsa.gsfc.nasa.gov> From: CORCORAN at ndadsa.gsfc.nasa.gov Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords Date: Fri, 18 Jun 1993 10:33:32 -0400 (EDT) On 18-JUN-1993 Lucio Chiappetti writes: > I am really perplexed by this proposal, and I fail to see a clear > distinction between what is used for inter-package data exchange (i.e. > to make the file readable, or at least understandable to a "foreign" > package) and what is used exclusively within a GIVEN package. > > My approach would be to use EXTNAME to classify in a broad sense the > kind of file. In particular in the high energy astrophysics context > the "kinds of files" I am using are :> > > 'SPECTRUM' count/s (or photon/s) spectra > 'RATE' time profile (anything vs time) > 'PHOTON LIST' list of photons or events > > in addition to these I consider images and response matrices > (but in my view they are images, not bintables, therefore do > not use EXTNAME) > > If each one of those supports variations, these are either in the > form (e.g. number and names of columns; and therefore are self-docu- > mented by other standard keywords like TTYPEn TFORMn etc.), or are > in the semantics (which is relevant within a particular package > only, and can be described by whatever optional keyword).> I think there are 2 problems using EXTNAME in the way you've described: 1) Having an EXTNAME = 'SPECTRUM' does not tell the user anything about the file contents, while EXTCLASS can be used to give the user information about what standard the file was constructed to follow. For example, if EXTCLASS = 'SPECTRUM', this tells the user that the file was constructed according to the OGIP spectrum extension document, so that for example, the data are given by a TTYPEN = 'COUNTS ' or TTYPEn = 'RATE ' and not 'SOURCE_CTS' or something else. This standardization is necessary in order to construct software that's multi-mission. 2) construction of unique filenames is not possible if EXTNAMEs are used to construct the filenames and if a given "class" of file occurs more than once in a dataset. > Being my primary interest in the possibility of EXCHANGING data > (i.e. importing/exporting them from/to my own package to/from other > packages) I would as far as possible avoid the use of "specialized" > convention, which may force to have a dedicated conversion utility > for each package, instead of a generic reader. The need for EXTCLASS, EXTTYPE etc. keywords was prompted so that a generic reader could be constructed for files of the same "class". This is not possible if we rely on EXTNAME to tell us the "class" of the file, since different groups have been using the same EXTNAMEs to mean different things. > As a conclusion, I do not see why you cannot use EXTNAME (instead > of EXTCLASS) for the top-level classification (to be kept to a FEW > classes, essentially the ones I listed above ... the exact names > can be agreed if you are concerned with imbedded blanks, or more > than 6 or 8 characters), and whatever YOU like for the bottom level > classification. > Still, I perceive that the top-level classification (EXTNAME) is > of relevance within the X-ray (HEAFITS) community (but not necessarily > within a larger - fitsbits - community), while the lower level > classification is only "private" to your software. I can't see how the use of EXTNAME to denote the top-level classification will allow the construction of a generic file reader for each class of file, which is I think a universally agreed-upon goal, given the fact that an EXTNAME='SPECTRUM' means different things to different groups. Even if we get all groups to agree that a file with EXTNAME = 'SPECTRUM' has certain required fields and keywords (a difficult goal to attain), this does not ensure that all files with EXTNAME = 'SPECTRUM' follow the adopted specifications, since a file with the EXTNAME = 'SPECTRUM' may have been constructed before the specifications were adopted. This argues for the creation of the EXTCLASS, EXTTYPE keywords. Cheers, Mike Corcoran ROSAT/OGIP FITS group From fitsbits-request Fri Jun 18 11:03:52 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1721" "Fri" "18" "June" "1993" "14:15:56" "GMT" "Greg Hennessy" "gsh7w at fermi.clas.Virginia.EDU " nil "39" "Re: Server \"nrao-fits\" now in WAIS-Directory-of-Servers" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06307; Fri, 18 Jun 93 11:03:52 EDT Return-Path: Message-Id: Organization: University of Virginia Path: cv3.cv.nrao.edu!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gsh7w References: From: gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Date: Fri, 18 Jun 1993 14:15:56 GMT Don Wells writes: #You are welcome, Greg. The person you should really thank is Archie #Warnock. Of course. I've mentioned to Archie before how useful I find WAIS to be in my work, so a public kudo seems in order. # GH> .. I.. note that you only catalog the text files.. there are lots # GH> of FITS images.. on your machine.. What are your thought of # GH> [making] these available through WAIS, so people can invoke # GH> saoimage on these files?.. # #I could certainly command the waisindex program to include the names #of the binary files in the index, but I am unsure how to tag them as #type "FITS" so that your client could invoke the appropriate display #tool; WAIS has a rich set of object types, but the set doesn't (yet) #include FITS. How does it tag Postscript? *I* knew the files were postscript by the *.ps extensions. I would expect, based on a thread a few months ago in sci.astro.fits, that a *.fit extension would imply FITS. Does WAIS allow arbitrary types? I simply guess at what format to edit the shell script ~/bin/wais-ps-display, and the Xwais.ad file, and my guess was correct. Does WAIS know about Postscript? #In my opinion the appropriate technology for this application is not #WAIS but WWW, the World-Wide-Web. Well, I haven't tried WWW, but have tried WAIS. My main point these days is to finish my thesis, not try nifty new software packages. At least there is a WAIS server running a quarter mile from me now, available for experimentation, while there is not a WWW server. *hint hint* -- -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w at virginia.edu UUCP: ...!uunet!virginia!gsh7w From fitsbits-request Fri Jun 18 15:13:03 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6289" "Fri" "18" "June" "1993" "20:12:37" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "134" "Re: Server \"nrao-fits\" now in WAIS-Directory-of-Servers" "^From:" nil nil "6"]) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06593; Fri, 18 Jun 93 15:13:03 EDT Return-Path: Message-Id: Organization: nrao Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells References: From: dwells at fits.CV.NRAO.EDU (Don Wells) Sender: fitsbits-request at fits.CV.NRAO.EDU To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Date: Fri, 18 Jun 1993 20:12:37 GMT In article dwells at fits.cv.nrao.edu (Don Wells) writes: [a followup about WAIS and WWW after Greg Hennessy asked whether WAIS could be used to fetch and display FITS files] Archie Warnock sent me the following response by Email: ------- Start of forwarded message ------- Message-Id: <9306181743.AA08731 at Hypatia.gsfc.nasa.gov> From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock) To: dwells at fits.CV.NRAO.EDU (Don Wells) Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Date: Fri, 18 Jun 93 13:43:02 EDT > You are welcome, Greg. The person you should really thank is Archie > Warnock. He has pioneered and advocated the WAIS technology in Awww, shucks . Thanks for the kind words. My news poster isn't working right now, but you can forward this to the net if you feel like it. > Wonderful! I asked Archie about the Postscript files when I was > developing my server, and he recommended that I include them to > permit the kind of experimentation which you have done. And I still haven't gotten our PS viewer working on hypatia yet, so I'm kinda flying blind. Someday, in my copious free time... > I could certainly command the waisindex program to include the names > of the binary files in the index, but I am unsure how to tag them as > type "FITS" so that your client could invoke the appropriate display > tool; WAIS has a rich set of object types, but the set doesn't (yet) > include FITS. You have but to ask :-) Try this (or something close): waisindex -d (wherever) -T FITS -t filename -a -export -r (all your FITS files) - -T forces the indexer to tag the files as type FITS, and the file name only will be indexed. I already did this with HTML documents - tag them as HTML, index the text contents and set up xmosaic as the HTML viewer. This allows WAIS to index arbitrary data formats (how's that for a group tie-in?), without having specific knowledge of them. As long as they're appropriately tagged, and as long as your client knows what to do with them, it works fine. > In my opinion the appropriate technology for this application is not > WAIS but WWW, the World-Wide-Web. Most people know the Web through the > name of its most sophisticated client implementation, xmosaic from I still tend to think of WAIS as the discovery tool and WWW/xmosaic as the retrieval/display tool. > NCSA at UIUC. WAIS is an excellent means for discovering relevant > *text* documents using keywords, and fetching those documents; WAIS is ^^^^^^^^ I _hate_ to see this! "Keywords" carries a different meaning in most contexts, and it frequently leads to confusion. "Keywords? We don' need no stinking keywords". WAIS index the _contents_ of documents, whatever that might be, and the user enters English phrases, not keywords. You and I may know that the retrieval engine, because it just matches words between query and document, is essentially "keyword-like", but Brewster's mom doesn't. Seriously, many users carry preconceptions of what "keyword" means, and it's something other than what WAIS does. > less well suited for dealing with non-textual material. WWW is an > excellent means for using hypertext links in text documents to point Actually, what WWW lets you do is hook objects of arbitrary type to you documents instead of forcing the user to go looking for them. OTOH, waisindex will index the (always-intelligently-named) file names just fine (which I did with my sample HST data server), and it indexes header data just fine, knowing to stop at the first non-ASCII character, so it'll work on FITS and PDS files (which I've also done). > files in various formats. I expect that it will be easy to get object > type "FITS" registered in the WWW community. There's a thought... > It appears to me that WAIS and WWW are complementary. The biggest > problem in using the Web is finding the hypertext page that points to > the resources you want. Once you find the first page it is easy to > find more relevant pages and to invoke arbitrary processes to do > arbitrary things to arbitrary objects. Finding things in text (like > home pages) is what WAIS does best! The xmosaic WWW client already As I mentioned above, this works just fine - I've already tried it. What we need is more WAIS indexes of HTML documents registered with Directory-of-servers. > me that it should be straight-forward for the WWW community to create > a symbiotic relationship between the two protocols. Absolutely - they really fit together very well. As soon (!) as NCSA builds in native WAIS support to xmosaic, rather than requiring a gateway server (which really isn't all that much of a hassle, either), it'll look quite seamless. > I am watching the WWW technology closely, and I expect that before the > end of 1993 I will activate a Web server on fits.cv.nrao.edu, with the > "home page" being the master READ.ME file of the existing anonymous I expect it'll be sooner than that. Ours is running already, and it seems fine. I'm building a soon-to-be public home page for STELAR with hooks to our databases, our anonymous FTP site and to some of the NSSDC's on-line services. Coming soon to a Web near you... > This is an exciting time for people who care about the classical > resource discovery problem --- practical solutions (Archie, Gopher, That's archie the program, not Archie the person :-) > WAIS, WWW) are already in hand, and the further development and > integration of these solutions is making rapid progress. Yes, yes, yes. This really is revolutionizing the way in which we find the information we use to do our science. Archie _______________________________________________________________________ - -- Archie Warnock Internet: warnock at hypatia.gsfc.nasa.gov - -- Hughes STX "Unix --- JCL For The 90s" - -- NASA/GSFC Project STELAR: WAIS to do science ------- End of forwarded message ------- -- Donald C. Wells Associate Scientist dwells at nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From fitsbits-request Sat Jun 19 03:37:28 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07284; Sat, 19 Jun 93 03:37:28 EDT Return-Path: Date: Sat, 19 Jun 93 16:34:27 JST From: Nishimura Shiro Message-Id: <9306190734.AA16318 at c1.mtk.nao.ac.jp> To: fitsbits at NRAO.EDU Subject: Japanese FITS Committee supports new FITS proposals Sender: fitsbits-request at fits.CV.NRAO.EDU I am glad to announce the result of voting for new FITS proposals by the Japanese FITS Committee. IMAGE Extension ; yes: 5, no: 0, unvoted: 1. Comments: Simple and convenient. BINARY TABLE Extension ; yes: 6, no: 0. Comments: It is a natural trend to extend to BINARY TABLE. AIPS already adopted this extension. It will be easier to look up and treat if character strings are NULL terminated. Inclusion of the Multidimensional Array Convention is desirable. There were divergent opinions for inclusion of the Variable Length Array. It is too complicated. It will be necessary. Blocking Factors ; yes: 6, no: 0. Comments: Standard procedure should be authorized. AIPS adopted 23040 Bytes. * * * * * * * * * * * * * * * * * * * * * * * * The Japanese FITS Committee comprises 6 members: Osamu KANAMITSU kanamitu at fukuoka-edu.ac.jp Yasuhiro MURATA murata at vsop.isas.ac.jp Eiji NISHIHARA onishih at c1.mtk.nao.ac.jp Shiro NISHIMURA (Chair) rnishim at c1.mtk.nao.ac.jp Toshiyuki SASAKI osasak2 at c1.mtk.nao.ac.jp Shigeomi YOSHIDA yoshida at kiso.ioa.s.u-tokyo.ac.jp ============================================================== Shiro Nishimura Astronomical Data Analysis Center National Astronomical Observatory Phone: 81-422-34-3709 Mitaka, Tokyo 181, Japan Fax : 81-422-34-3608 From fitsbits-request Sat Jun 19 16:21:03 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09185; Sat, 19 Jun 93 16:21:03 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 19 Jun 1993 20:14:01 GMT From: emv at garnet.msen.com (Edward Vielmetti) Message-Id: <1vvs29$8c0 at nigel.msen.com> Organization: Msen, Inc. -- Ann Arbor, Michigan Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!usc!sdd.hp.com!caen!nigel.msen.com!garnet.msen.com!emv References: Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Sender: fitsbits-request at fits.CV.NRAO.EDU Don Wells (dwells at fits.cv.nrao.edu) wrote: : I could certainly command the waisindex program to include the names : of the binary files in the index, but I am unsure how to tag them as : type "FITS" so that your client could invoke the appropriate display : tool; WAIS has a rich set of object types, but the set doesn't (yet) : include FITS. The right place to go to register new file data types is the "Internet Assigned Numbers Authority", which keeps track of such things for file content types for multi-media mail (MIME) and also for other applications programs that are using the MIME typing system as a standard way of naming things. Registration involves coming up with a reference to a printed spec, an analysis of the security implications of mailing such things around (do FITS documents have code in them that could instruct a viewer to do an "rm -rf /" ?), and any notes to encodings it the data formats are not 7-bit ascii. Edward Vielmetti, vice president for research, Msen Inc. emv at Msen.com Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563) From fitsbits-request Sun Jun 20 22:24:11 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01688; Sun, 20 Jun 93 22:24:11 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: Mon, 21 Jun 1993 02:16:45 GMT From: marca at ncsa.uiuc.edu (Marc Andreessen) Message-Id: Organization: Nat'l Center for Supercomputing Applications Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!128.174.5.61!marca References: Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Sender: fitsbits-request at fits.CV.NRAO.EDU In article dwells at fits.cv.nrao.edu (Don Wells) writes: In my opinion the appropriate technology for this application is not WAIS but WWW, the World-Wide-Web. Most people know the Web through the name of its most sophisticated client implementation, xmosaic from NCSA at UIUC. WAIS is an excellent means for discovering relevant *text* documents using keywords, and fetching those documents; WAIS is less well suited for dealing with non-textual material. WWW is an excellent means for using hypertext links in text documents to point at objects of arbitrary type. The links (called URLs [Universal Resource Locators] in WWW jargon) can code the object type, and many existing examples of WWW documents include pointers to digital image files in various formats. I expect that it will be easy to get object type "FITS" registered in the WWW community. Now that you mention it, I'll make sure the next version of Mosaic will be able to handle FITS data. A side note: readers of this group may be interested to know that future versions of Mosaic will be able to browse HDF and netCDF data files -- accessing such a file will present you with a hypermedia description and interface to its structure and contents. For more information, including screen dumps, see this document: http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/hdf-browsing.html ...within Mosaic (ftp to ftp.ncsa.uiuc.edu in /Mosaic if you're not already running it). Cheers, Marc -- Marc Andreessen Software Development Group National Center for Supercomputing Applications marca at ncsa.uiuc.edu From fitsbits-request Mon Jun 21 17:32:11 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02877; Mon, 21 Jun 93 17:32:11 EDT Return-Path: Date: Mon, 21 Jun 93 17:31:19 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9306212131.AA14234 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Comments on OGIP on proposal for RA/Dec keywords Sender: fitsbits-request at fits.CV.NRAO.EDU Maureen Conroy wrote: >Comments on the OGIP RA/DEC keyword proposal > >It seems to me that most of the information that the OGIP >is trying to record in FITS has already been provided by, or can be >derived from, the World Coordinate System (WCS) keywords. Furthermore, WCS >provides for a large number of coordinate systems and is not restricted to >RA and Dec. Using keywords which REQUIRE RA and Dec lacks generality. It is true that in the case of FITS images the standard WCS keywords may provide at least some of the information give by the proposed new RA/DEC keywords. But I think the main use for these new keywords (at least within the HEASARC) will be in FITS BINARY tables where the usage of WCS type keywords is not well established. Even in the case of FITS images, it is sometimes still useful to provide these simple RA/DEC keyword as an aid for someone who is browsing through the data, or for constructing simple catalogs which describe a collection of FITS images. It is a lot easier just to read these keywords than it is to perform the complicated CD matric calculations. And finally there are cases such as where the FITS 'image' is a one-dimensional spectrum of an astronomical object. There may well be WCS keywords associated with this FITS image, but they will likely not tell you anything about the position of the object in the sky. In this case we would need the proposed RA/DEC keywords to provide this information. -Bill Pence From fitsbits-request Mon Jun 21 18:00:22 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02901; Mon, 21 Jun 93 18:00:22 EDT Return-Path: Date: Mon, 21 Jun 93 17:59:22 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9306212159.AA14257 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords (v 93-Jun-17) Sender: fitsbits-request at fits.CV.NRAO.EDU Lucio Chiappetti wrote (in reference to the EXTCLASS and EXTTYPE keywords): > My approach would be to use EXTNAME to classify in a broad sense the > kind of file. In particular in the high energy astrophysics context > the "kinds of files" I am using are : > > 'SPECTRUM' count/s (or photon/s) spectra > 'RATE' time profile (anything vs time) > 'PHOTON LIST' list of photons or events I think many of us would have liked to use EXTNAME for this purpose, but the EXTNAME keyword is already being used by different groups in significantly different ways. Some use it as a unique file name, others use it as a very long discriptive string. So it appears too late to try to propose a standard convention for this keyword because it would be expensive for some of these groups to revise their software. Plus, there are already many FITS files in data archives that would not conform to this new restricted usage of the EXTNAME keyword. So, it seems more practical to invent a new keyword (EXTCLASS) for this purpose. -Bill Pence From fitsbits-request Tue Jun 22 03:38:06 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03252; Tue, 22 Jun 93 03:38:06 EDT Return-Path: Message-Id: <9306220738.AA03246 at fits.cv.nrao.edu> Date: Tue, 22 Jun 1993 08:36:43 +0100 Reply-To: ptw at star.rl.ac.uk From: ptw at rlstar.bnsc.rl.ac.uk (P.T.Wallace) To: fitsbits at fits.CV.NRAO.EDU Subject: Re: OFSP proposal for standard RA,Dec keywords X-Vms-To: SMTP%"fitsbits at fits.cv.nrao.edu" X-Vms-Cc: PTW Sender: fitsbits-request at fits.CV.NRAO.EDU A small technical point - if the RADECSYS/EQUINOX proposal is adopted, I suggest that the text should not say that EQUINOX is in years AD, but that it is "either a Besselian epoch or a Julian epoch as appropriate for the specified RADECSYS, e.g. 1950.0 for 'FK4' or 2000.0 for 'FK5'". From fitsbits-request Tue Jun 22 09:47:28 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04225; Tue, 22 Jun 93 09:47:28 EDT Return-Path: Message-Id: <9306221347.AA04219 at fits.cv.nrao.edu> Date: Tue, 22 Jun 1993 15:45:08 +0200 From: forveill at gag.observ-gr.fr (Thierry Forveille) Posted-Date: Tue, 22 Jun 1993 15:45:08 +0200 To: fitsbits at fits.CV.NRAO.EDU, pence at tetra.gsfc.nasa.gov Subject: Re: Comments on OGIP on proposal for RA/Dec keywords In-Reply-To: <9306212131.AA14234 at tetra.gsfc.nasa.gov> References: <9306212131.AA14234 at tetra.gsfc.nasa.gov> Sender: fitsbits-request at fits.CV.NRAO.EDU William Pence writes: > Maureen Conroy wrote: > > >Comments on the OGIP RA/DEC keyword proposal > > > >It seems to me that most of the information that the OGIP > >is trying to record in FITS has already been provided by, or can be > >derived from, the World Coordinate System (WCS) keywords. Furthermore, WCS > >provides for a large number of coordinate systems and is not restricted to > >RA and Dec. Using keywords which REQUIRE RA and Dec lacks generality. > > It is true that in the case of FITS images the standard WCS keywords > may provide at least some of the information give by the > proposed new RA/DEC keywords. But I think the main use for these > new keywords (at least within the HEASARC) will be in FITS BINARY > tables where the usage of WCS type keywords is not well established. > The fact that the WCS keywords are not yet widely used in binary tables should not be a compelling argument: neither is the new proposed convention, so why not use an existing quasi-standard instead of reinventing the wheel? > Even in the case of FITS images, it is sometimes still useful to > provide these simple RA/DEC keyword as an aid for someone who is > browsing through the data, or for constructing simple catalogs > which describe a collection of FITS images. It is a lot easier > just to read these keywords than it is to perform the complicated > CD matric calculations. > I find redundancy in FITS headers a real nuisance. What should I do if an image provide both a WCS description and RA/DEC keywords, and they are inconsistent, maybe by just a few arcseconds? The difference maybe totally negligible for some data (say in a COBE spectrum, maybe due to totally unimportant roundoff), and huge for others (an HST FOC image). The decision has to be made by the user, which is just what we want to avoid. I have a general impression that most of the recently suggested modifications to FITS (specially from the high energy community) don't take enough account of the interchange aspect in FITS. This aspect has been both the initial motivation for developing FITS and the reason for its success. It is all right if some people find it usefull as their internal format as well, but only as long as the basic interchange aspect is preserved. > And finally there are cases such as where the FITS 'image' > is a one-dimensional spectrum of an astronomical object. > There may well be WCS keywords associated with this FITS image, > but they will likely not tell you anything about the position > of the object in the sky. In this case we would need the > proposed RA/DEC keywords to provide this information. > Use of WCS keywords to store the position for a one dimensional spectrum is actually well established in the radioastronomical community. Spectra are stored as nominally three dimensional images, two of which are degenerate (i.e. have NAXISi = 1). The non degenerate axis is used for frequency (could be wavelength, or energy, or wavenumber, depending on your prefered convention...), and the two degenerate axes are used for the sky position (a fourth axis is sometimes used to store the polarisation state). This description turns out to be extremely convenient, since it provides for the notion of offsets relative to a central position (which is needed to reflect the usual data organisation): the central position is stored as CRVALi, CRPIXi is set to zero, and the offset is stored in CDELTi (or the equivalent CD keyword). This effectively considers the spectrum has a subset of an underlying datacube (which will frequently be reassembled at the end of the reduction procedure, though it is observed piecewise). Thierry Forveille Observatoire de Grenoble From fitsbits-request Tue Jun 22 12:26:03 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04307; Tue, 22 Jun 93 12:26:03 EDT Return-Path: Date: Tue, 22 Jun 93 12:25:12 EDT From: pence at tetra.gsfc.nasa.gov (William Pence) Message-Id: <9306221625.AA14975 at tetra.gsfc.nasa.gov> To: fitsbits at fits.CV.NRAO.EDU Subject: Re: Comments on OGIP on proposal for RA/Dec keywords Sender: fitsbits-request at fits.CV.NRAO.EDU In reply to Thierry Forveille's comments, the existing WCS keywords and the proposed new RA/DEC keywords serve quite different purposes and are not redundant or interchangeable. The purpose of our new proposal is to standarize the keyword names for the RA and DEC keywords that are already needed and being used by many missions. So we are not inventing entirely new keywords; we're just proposing standard names for existing keywords already in use by a number of groups. The other point is that the standard WCS keywords are simply not appropriate in some of the FITS files we produce. Here are 2 simple examples: 1. The primary array of the FITS files is often just a dummy array (NAXIS=0) and all the real data are in the following extensions. However,the primary array keywords are often used to to give a general description of the contents of the FITS file, includeing the name of the object and its RA and DEC. 2. The X-ray data is often stored in the form of FITS BINTABLES which list the characteristics of each detected X-ray photon, (one photon per row of the table). In a simple example, 2 of the columns of the table may list the RA and DEC (in degrees) of each event. In this case there is simply no need for WCS type keywords since there is no pixel-to-sky transformation involved. In both these cases we need a way of giving the RA and DEC values in the headers, but the WCS keywords would not be at all appropriate for this purpose. -Bill Pence From fitsbits-request Tue Jun 22 15:10:31 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04387; Tue, 22 Jun 93 15:10:31 EDT Return-Path: To: fitsbits at fits.CV.NRAO.EDU Date: 22 Jun 93 18:33:02 GMT From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Message-Id: Organization: NASA Goddard Space Flight Center -- InterNetNews site Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!Hypatia!leb References: Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers Sender: fitsbits-request at fits.CV.NRAO.EDU gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) writes: ># GH> .. I.. note that you only catalog the text files.. there are lots ># GH> of FITS images.. on your machine.. What are your thought of ># GH> [making] these available through WAIS, so people can invoke ># GH> saoimage on these files?.. ># >#I could certainly command the waisindex program to include the names >#of the binary files in the index, but I am unsure how to tag them as >#type "FITS" so that your client could invoke the appropriate display >#tool; WAIS has a rich set of object types, but the set doesn't (yet) >#include FITS. Actually, Jim Fullton, of the Clearinghouse for Network Information Discovery and Retrieval (CNIDR) had implemented a FITS file index and server for WAIS while he was at the University of North Carolina. The stock indexer has a neat little feature of stopping whenever it hits binary, non-ASCII, data. So you can index the files pretty easily. Just don't expect to get much information back by querying about "NAXIS". :-) It isn't very hear to add the datatype tagging and "headline" code to the indexer (a headline is the one-line textual description you get back from an initial query). It might take a little more effort to make a general headline checker for FITS that is geared to a specific keyword or keywords, but in general the task is nearly trivial. That's why I like this stuff so much. >How does it tag Postscript? *I* knew the files were postscript by the >*.ps extensions. I would expect, based on a thread a few months ago in >sci.astro.fits, that a *.fit extension would imply FITS. Does WAIS >allow arbitrary types? I simply guess at what format to edit the shell >script ~/bin/wais-ps-display, and the Xwais.ad file, and my guess was >correct. Does WAIS know about Postscript? The datatype of a document is indexed along with the document and held by the server. There is a field in the RequestResponse APDU returned to your client that gives the datatype(s) of that document. An important feature is that a document can have multiple datatypes. This is how project STELAR works. We indexed the abstracts for the text searches and logically tied them together with the scanned pages from the articles within the server. When you click on an abstract title, xwais asks you if you want to see the abstract, first page TIFF file, or all the TIFF files in the article. Real slick and built right out of the box with just a li-i-i-tle tweaking. >#In my opinion the appropriate technology for this application is not >#WAIS but WWW, the World-Wide-Web. >Well, I haven't tried WWW, but have tried WAIS. My main point these >days is to finish my thesis, not try nifty new software packages. At >least there is a WAIS server running a quarter mile from me now, >available for experimentation, while there is not a WWW server. >*hint hint* If you try WWW, you'll want to write your thesis about *it*, it's that cool. Remember that we are in the global network community, and in client server applications it doesn't matter a bit if the server is down the road or across the nation. Maybe it matters a little if it's overseas, but not nearly as much as it once did. >-- >-Greg Hennessy, University of Virginia > USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA > Internet: gsh7w at virginia.edu > UUCP: ...!uunet!virginia!gsh7w -- -- Lee E. Brotzman Internet: leb at hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB at GIBBS From fitsbits-request Wed Jun 23 05:34:51 1993 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04854; Wed, 23 Jun 93 05:34:51 EDT Return-Path: Organization: Istituto di Fisica Cosmica e Tecnologie Relative Date: Wed, 23 Jun 1993 10:45:50 +0200 (MET DST) From: Lucio Chiappetti Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords To: fitsbits at fits.CV.NRAO.EDU In-Reply-To: <930618103332.22800397 at ndadsa.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: fitsbits-request at fits.CV.NRAO.EDU I'd like to continue the discussion about EXTNAME etc. I'll enclose below some comments to Mike Corcoran's posting. I'd also like some of the guys who proposed the BINTABLE extension and/or who are mantaining the standards to comment on the issue. From the binary table document (I'm using Appendix A of the NOST document) I see there are already three (optional reserved) keywords to define extensions (EXTNAME, EXTVER, EXTLEVEL), although their intended usage is not altogether clear (otherwise we won't be here discussing :-) ) and I'm afraid of proliferation of different conventions. On Fri, 18 Jun 1993 CORCORAN at ndadsa.gsfc.nasa.gov wrote: > 2) construction of unique filenames is not possible if EXTNAMEs are used to > construct the filenames and if a given "class" of file occurs more than > once in a dataset. I (at least) never said or intended to use EXTNAME as "filetype". By filetype I mean the component of a full file name in a form like : /path/path/filename.filetype or {path.path]filename.filetype;ver Also from the NOST document, Appendix A, it is not obvious that EXTNAME was intended for that. Concerning the habit of sticking more extensions in the same FITS file, I regard this as something to be avoided (however that should be irre- levant to you since you read the FITS extensions directly and do not read them into separate "native" (IRAF, MIDAS or whatever) files). I'll use that only for TRANSPORT and not for native storage, in one particular case (and anyhow I use the IMAGE extension in such case). The conventions to give a filename.filetype are by definition dependent on whatever package one is using. I personally use a FILENAME keyword which contains the file name without path (site-dependent), and without filetype (package-dependent). If a filetype is needed (as a recommended value), one could add a FILETYPE keyword. It is however true that I construct a default filetype based on the "content" of the file. This occurs when I read back from FITS to my\ native format. My default filetypes are ... guess what : .image .spectrum .rate .photon .matrix (and .histo) My native format is not FITS, but is one-to-one mappable. When reading a file, I use whatever filetype the user supplied (if he did, and if he wants to call a spectrum pinco.panco or pinco.photon instead of pinco.spectrum that is his damn business), or if he did not supply one (as in the majority of the cases, jsut said "pinco") I construct it from "context" (a fitting program will expect .spectrum, an image display one .image etc.). Then when I have constructed the file name, I open the file and check it is what expected (if not error exir). The check uses a magic number in the file header which is structured in four parts (none of this is FITS, but some of this is used to generate FITS keywords when I convert the file to FITS ... most of my header keywords have the same name of FITS keywords, but a few FITS keywords get generated on the fly) : XAS\001 identifies that the file conforms to my convention (this is so far ignored when converting to FITS) xxx\002 where xxx=IMG or BIN, indicating the file is an image or a binary table (this controls conversion to FITS as a primary HDU, or an XTENSION='BINTABLE') yyy\003 where (for xxx=BIN) yyy=SPE,PHO,TIM ... indicating the file is a spectrum, photon list, time profile .... (in FITS this generates EXTNAME) zzz\004 is a code indicating the operating system on which the file was written (this is obviously irrelevant to FITS) So my hierarchy is : is the file according to my convention (yes); is the file an image or a bintable ? and if a bintable what is it ? I do not feel the need of any further specialization, since I kept the definition of different types at minimum, according to Ockham's razor ("file structures non sunt multiplicanda praeter necessitatem") > 1) Having an EXTNAME = 'SPECTRUM' does not tell > the user anything about the file contents, while EXTCLASS can be used to > give the user information about what standard the file was constructed to > follow. For example, if EXTCLASS = 'SPECTRUM', this tells the user that > the file was constructed according to the OGIP spectrum extension document, > so that for example, the data are given by a TTYPEN = 'COUNTS ' or TTYPEn = > 'RATE ' and not 'SOURCE_CTS' or something else. This standardization > is necessary in order to construct software that's multi-mission. > what do you mean exactly by multimission ? i) designed to support any future mission which will be compliant to the standard data format, and any other past and future mission which is not compliant by means of converters OR ii) designed to support directly the many different data formats and conventions already supported by past missions ? Me, I'd go for i) The goal is : make sure that the files contain ALL NECESSARY information and the conventions used are documented (if any spectra contain for instance low and high channel boundary energy, cts/s and errors, AND the name of the columns are documented, a converter manipulating table columns can always be written ... in Fortran, MIDAS, IRAF, Ftools or whatever ....) > .... could be constructed for files of the same "class". This is not > possible if we rely on EXTNAME to tell us the "class" of the file, since > different groups have been using the same EXTNAMEs to mean different > things. > I can't see how .... > ... EXTNAME='SPECTRUM' means different things to different groups. Even if > we get all groups to agree that a file with EXTNAME = 'SPECTRUM' has > certain required fields and keywords (a difficult goal to attain), this > does not ensure that all files with EXTNAME = 'SPECTRUM' follow the adopted > specifications, since a file with the EXTNAME = 'SPECTRUM' may have been > constructed before the specifications were adopted. This argues for the > creation of the EXTCLASS, EXTTYPE keywords. As I said, get rid of the past (hide them behind converters), and try to have at least all high energy groups to agree they mean the same thing ! +-------------------------------------------------------------------------+ | I feel that what is needed here is NOT a convention about EXTNAME, or | | any lower level convention, but just a keyword which allows the user to | | readily identify ... the conventions according to which the file has | | been written (the equivalent of the first field in my magic number). | | | | This could be in your case ORIGIN='OGIP' or EXTNAME='OGIP' or | | CONVENTN='OGIP'. | +-------------------------------------------------------------------------+ Is this an acceptable and useful thing to do ? After this (since it is not covered by the full standard) you could do whatever you like with lower level keywords, I could do whatever I like, anybody else can do whatever one likes ... and one can always read the file as a generic binary table and manipulate it within one's package of choice ... or write a converter from your convention to mine (for some cases I have a prototype), or from your to somebody else's etc. ----------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR Milano | U N I C U I Q U E via Bassini 15 - I-20133 Milano - Italy | System Manager Internet: LUCIO at IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: | ----------------------------------------------------------------------------- From fitsbits-request Wed J