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: <news at cv3.CV.NRAO.EDU>
Message-Id: <C7yt0n.K9B at news.Hawaii.Edu>
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: <GEORGE at HEAGIP.GSFC.NASA.GOV>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Jun1224221 at fits.cv.nrao.edu>
Organization: nrao
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
References: <C7yt0n.K9B at news.Hawaii.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: Appropriate units for angular keywords
Date: Wed, 2 Jun 1993 03:42:21 GMT

In article <C7yt0n.K9B at news.Hawaii.Edu> 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: <news at cv3.CV.NRAO.EDU>
Message-Id: <C7z39v.FB at news.Hawaii.Edu>
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:  <C7yt0n.K9B at news.Hawaii.Edu>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Jun3120159 at fits.cv.nrao.edu>
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: <news at cv3.CV.NRAO.EDU>
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:<MSDOS.GRAPHICS>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: <news at cv3.CV.NRAO.EDU>
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)
<NSSDCA.GSFC.NASA.GOV MultiNet FTP Server Process 2.2(11) at Mon 24-Dec-90
 9:17AM-EST

NSSDCA.GSFC.NASA.GOV>user anonymous
<anonymous user ok. Send real ident as password.

Password: MEV at NDADSA.GSFC.NASA.GOV
<Guest User MEV at NDADSA.GSFC.NASA.GOV logged into ANON_DIR:[000000] at Mon
 24-Dec-90 09:17, job 202003a1.
<Directory and access restrictions apply

NSSDCA.GSFC.NASA.GOV>cd fits
<Connected to ANON_DIR:[FITS].

NSSDCA.GSFC.NASA.GOV>get aareadme.doc;1 readme.
<VMS retrieve of ANON_DIR:[FITS]AAREADME.DOC;1 started.
<Transfer completed.  316 (8) bytes transferred.

NSSDCA.GSFC.NASA.GOV>quit
<QUIT command received. Goodbye.

======================================================================

Printed copies may be obtained from the NOST Librarian.  The NOST can
be reached as follows: 

(Postal) NASA/OSSA 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 announcement in your request.  If a large 
volume of requests for printed copies is received initially, there may 
be some delay in the distribution.

For further information send electronic mail to the FITS Support
office at
	(DECnet) 	NCF::FITS
	(Internet)	fits at nssdca.gsfc.nasa.gov

or telephone at +1-301-513-1634.  The telephone is equipped with a voice
mail system to take messages from touch tone phones if no one answers.

From dwells  Fri Jun 11 15:21:13 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1811" "Fri" "11" "June" "93" "15:21:09" "EDT" "chaganti at ssl.DNET.NASA.GOV" "chaganti at ssl.DNET.NASA.GOV" nil "57" "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 AA03247; Fri, 11 Jun 93 15:21:13 EDT
Resent-Message-Id: <9306111921.AA03247 at fits.cv.nrao.edu>
Return-Path: <dwells at fits.CV.NRAO.EDU>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Jun11164630 at fits.cv.nrao.edu>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Jun14181120 at fits.cv.nrao.edu>
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: <GEORGE at ROSGIP.GSFC.NASA.GOV>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Jun17163934 at fits.cv.nrao.edu>
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: <GEORGE at HEAGIP.GSFC.NASA.GOV>
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: <mo at cfa234.harvard.edu>
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: <mo at cfa234.harvard.edu>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <C8sp18.5Eu at murdoch.acc.Virginia.EDU>
Organization: University of Virginia
Path: cv3.cv.nrao.edu!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gsh7w
References: <DWELLS.93Jun17163934 at fits.cv.nrao.edu>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <MARCA.93Jun17220220 at wintermute.ncsa.uiuc.edu>
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: <DWELLS.93Jun17163934 at fits.cv.nrao.edu> <C8sp18.5Eu at murdoch.acc.Virginia.EDU>
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 <C8sp18.5Eu at murdoch.acc.Virginia.EDU>
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: <lucio at poseidon.ifctr.mi.cnr.it>
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
In-Reply-To: <930617144411.20e000bd at ROSGIP.GSFC.NASA.GOV>
Message-Id: <Pine.3.05.9306180958.C22131-c100000 at poseidon.ifctr.mi.cnr.it>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
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:   <please do not use any more>     |                                    
-----------------------------------------------------------------------------   

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: <lucio at poseidon.ifctr.mi.cnr.it>
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
In-Reply-To: <930617173750.20a00204 at HEAGIP.GSFC.NASA.GOV>
Message-Id: <Pine.3.05.9306181007.F22131-c100000 at poseidon.ifctr.mi.cnr.it>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Jun18093651 at fits.cv.nrao.edu>
Organization: nrao
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
References: <DWELLS.93Jun17163934 at fits.cv.nrao.edu> <C8sp18.5Eu at murdoch.acc.Virginia.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: Server "nrao-fits" now in WAIS-Directory-of-Servers
Date: Fri, 18 Jun 1993 14:36:51 GMT

In article <C8sp18.5Eu at murdoch.acc.Virginia.EDU>
        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: <dwells>
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: <dwells>
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: <CORCORAN at ndadsa.gsfc.nasa.gov>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <C8tMAK.24w at murdoch.acc.Virginia.EDU>
Organization: University of Virginia
Path: cv3.cv.nrao.edu!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gsh7w
References: <DWELLS.93Jun17163934 at fits.cv.nrao.edu> <C8sp18.5Eu at murdoch.acc.Virginia.EDU> <DWELLS.93Jun18093651 at fits.cv.nrao.edu>
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: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Jun18151237 at fits.cv.nrao.edu>
Organization: nrao
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
References: <DWELLS.93Jun17163934 at fits.cv.nrao.edu> <C8sp18.5Eu at murdoch.acc.Virginia.EDU> <DWELLS.93Jun18093651 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: Server "nrao-fits" now in WAIS-Directory-of-Servers
Date: Fri, 18 Jun 1993 20:12:37 GMT

In article <DWELLS.93Jun18093651 at fits.cv.nrao.edu>
    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 <blushing>.  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: <rnishim at c1.mtk.nao.ac.jp>
Date: Sat, 19 Jun 93 16:34:27 JST
From: Nishimura Shiro         <rnishim at c1.mtk.nao.ac.jp>
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: <news at cv3.CV.NRAO.EDU>
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: <DWELLS.93Jun18093651 at fits.cv.nrao.edu>
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: <news at cv3.CV.NRAO.EDU>
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: <MARCA.93Jun20211646 at wintermu.ncsa.uiuc.edu>
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: <DWELLS.93Jun17163934 at fits.cv.nrao.edu> <C8sp18.5Eu at murdoch.acc.Virginia.EDU> <DWELLS.93Jun18093651 at fits.cv.nrao.edu>
Subject: Re: Server "nrao-fits" now in WAIS-Directory-of-Servers
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article <DWELLS.93Jun18093651 at fits.cv.nrao.edu>
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: <pence at tetra.gsfc.nasa.gov>
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: <pence at tetra.gsfc.nasa.gov>
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: <ptw at rlstar.bnsc.rl.ac.uk>
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: <forveill at gag.observ-gr.fr>
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: <pence at tetra.gsfc.nasa.gov>
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: <news at cv3.CV.NRAO.EDU>
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: <leb.740773982 at Hypatia>
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: <DWELLS.93Jun17163934 at fits.cv.nrao.edu> <C8sp18.5Eu at murdoch.acc.Virginia.EDU> <DWELLS.93Jun18093651 at fits.cv.nrao.edu> <C8tMAK.24w at murdoch.acc.Virginia.EDU>
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: <lucio at poseidon.ifctr.mi.cnr.it>
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
Date: Wed, 23 Jun 1993 10:45:50 +0200 (MET DST)
From: Lucio Chiappetti <lucio at IFCTR.MI.CNR.IT>
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: <Pine.3.05.9306231049.E6844-e100000 at poseidon.ifctr.mi.cnr.it>
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:   <please do not use any more>     |                                    
-----------------------------------------------------------------------------   

From fitsbits-request  Wed Jun 23 08:35:58 1993
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA05758; Wed, 23 Jun 93 08:35:58 EDT
Return-Path: <arots at xebec.gsfc.nasa.gov>
Date: Wed, 23 Jun 93 08:34:58 EDT
From: arots at xebec.gsfc.nasa.gov (Arnold Rots)
Message-Id: <9306231234.AA21521 at xebec.gsfc.nasa.gov>
To: pence at tetra.gsfc.nasa.gov
Subject: Re: Comments on OGIP on proposal for RA/Dec keywords
Cc: fitsbits at NRAO.EDU
Sender: fitsbits-request at fits.CV.NRAO.EDU

Let me make another comment on Thierry Forveille's remarks.

Basically, the way the FITS rules have been written cause tricks
that work for primary data arrays not to work for table extensions.

Thierry suggests that the HEA community adopt the habits of the
radio and optical communities by using two degenerate axes for
establishing celestial positions - with the added bonus of being
able to take advantage of the WCS coordinate conventions.

I'd be strongly in favor of this (using similar conventions in
as many sub-communities, and all that), but here is the problem:
in the primary data array one is free to define as many coordinate
axes as one pleases, but that freedom is lost when the data is
stored in table extensions (as is the case for most HEA data).
For the extension itself, one is limited to NAXIS=2, and both
of those axes have a very specific meaning (length of the rows
and number of rows) which one cannot tinker with to insert RAs
and DECs.  It has been suggested that one could use the primary
header to convey the position in a manner similar to what one
would use if the primary array contained a spectrum (Thierry's
example).  Unfortunately, in many cases the primary array is
empty, requiring its NAXIS to be zero.

What this amounts to is that if one stores one's data in table
extensions and has an empty primary array, there is no way to
implement Thierry's suggestion.  Possible alternatives are:
1. A dummy primary array (give it just two degenerate axes,
RA and DEC); I would consider this a kludge.
2. Add some "random" CRVALn keywords in the header that bear no
relation to any existing axes but carry the position information;
an even worse kludge.
3. Add RA and DEC as degenerate axes to the vectors stored in each
cell - i.e., in the column headings.  This gets into the duplication
issue (an indeed undesirable feature); alternatively one could put it
in only one column heading, but that is very arbitrary and dangerous,
too.
4. Add two columns in the table containing RA and DEC.  This is
overkill.

The bottom line is that there is no really satisfactory solution.  I
hope this makes you a little more sympathetic to our plight.

  - Arnold Rots
From fitsbits-request  Wed Jun 23 10:58:45 1993
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA05837; Wed, 23 Jun 93 10:58:45 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: 23 Jun 93 14:13:39 GMT
From: thompson at serts.gsfc.nasa.gov (William Thompson)
Message-Id: <thompson.740844819 at serts.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson
References: <Pine.3.05.9306231049.E6844-e100000 at poseidon.ifctr.mi.cnr.it>
Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords
Sender: fitsbits-request at fits.CV.NRAO.EDU

Just to put my 2 cents worth in.  For the SOHO/CDS FITS data files, we were
planning to use EXTNAME to uniquely identify the data stored within the
extension, not what kind of data it is--all our data is of the same kind.  We
currently envision only using one extension (binary table) per file, with the
primary HDU being empty.  However, it does seem advantageous to retain the
capability of merging several related datasets in separate extensions within a
single FITS file.

Bill Thompson
From fitsbits-request  Fri Jun 25 16:02:59 1993
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA11873; Fri, 25 Jun 93 16:02:59 EDT
Return-Path: <pence at tetra.gsfc.nasa.gov>
Date: Fri, 25 Jun 93 16:01:49 EDT
From: pence at tetra.gsfc.nasa.gov (William Pence)
Message-Id: <9306252001.AA00325 at tetra.gsfc.nasa.gov>
To: fitsbits at fits.CV.NRAO.EDU
Subject: Table Sort Keyword
Cc: pence at tetra.gsfc.nasa.gov
Sender: fitsbits-request at fits.CV.NRAO.EDU

FITS tables (ASCII or BINTABLE) are often sorted on the value of one
or more columns in the table.  In order to most efficiently access the
data in these tables some software may need to know how the table was
sorted.  Thus it would be useful if we can define a header keyword(s)
which will specify how the table is sorted.

This subject has been discussed internally at the HEASARC (plus a
few others) and this posting is an attempt to summarize our preliminary
ideas.  We would appreciate further comments or ideas on this topic
from the the FITS community.

The basic idea is to have a keyword like:

TSORTKEY = 'X, Y, TIME'

Which lists the primary and secondary sort keys.  In this example, the
table is primarily sorted by the value of the X column, then all the
rows that have the same X value are sorted by Y, and finally all the
rows that have the same X and the same Y values are sorted by the TIME
values.

There was some discussion of alternate keyword names, e.g., TSORT, or
SORT, or SORTKEY, but TSORTKEY seemed to be acceptable to most people.

There was also some discussion of whether is was required to separate
the list of column names with commas, or whether just spaces would be
sufficient.  Most of us felt that it was safer to require commas.

Clive Page added that it was also necessary to specify whether the rows
were sorted in increasing, or decreasing order of the column value.  He
suggested the convention of placing a minus sign in front of the column
name to denote a descenting order sort, as in

TSORTKEY = '-X, Y, TIME'    / table is sorted in decreasing order of X

Tom McGlynn then offered alternative sorting keyword conventions
of the form

TSORT1   = 'FIELD1, DESCENDING'			/ Sort in descending order
TSORT2   = 'FIELD2  '
TSORT3   = 'FIELD3, SKIP=3,LENGTH=5'               / Use bytes 4-8 for the sort
..  here any information after the comma is ignored unless the reader
     knows how to handle it.

    or

SORT1   = 'FIELD1  '
SRTOP1  = 'DESCENDING'
..  here a reader can interpret the sort fields and need not worry 
     about parsine the options unles they are of interest.

While this is less concise than the original suggestion, it is perhaps
more generally extensible and more in keeping with existing FITS
conventions.

The previous example also raises the issue how one would specify that the
table was sorted on a substring of characters in an ASCII column, such as
sorting an 8A column on the last 4 character in the field. 
In the original scheme, perhaps this could be specified by:

TSORTKEY = 'NAME(5:8), X, Y' /sorted on the 5th thru 8th characters of the NAME column

A more basic question is whether it should even be allowed to sort a
column on a subpart of the field.  I don't think this is allowed in
general in relational databases.

A related issue is whether sorting of vector columns (with numeric
data) should be allowed.  Is there a well defined way to sort vectors?

Tom McGlynn also raised the question of whether one should have the
option to sort a numeric column in an ASCII table either by the
numerical order, OR by the ASCII sort order of the internal ASCII string
representation of the column.  Personnally, I don't think this option
should be allowed, and a table column should be sorted only based on
the implied data type of the TFORM column, and not by it's ASCII
internal representation.

Finally, one issue that was not discussed by us but would need to be
resolved is how to handle undefined elements in a table.  Presumably
all the NUL value fields should all appear either first or last in the
sorted order.

Any comments??

From fitsbits-request  Mon Jun 28 11:22:43 1993
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA18644; Mon, 28 Jun 93 11:22:43 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Mon, 28 Jun 1993 16:22:27 GMT
From: dwells at fits.CV.NRAO.EDU (Don Wells)
Message-Id: <DWELLS.93Jun28112227 at fits.cv.nrao.edu>
Organization: nrao
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
References: <20mtaiINN61h at uwm.edu>
Subject: Re: FITS viewer?
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article <20mtaiINN61h at uwm.edu> gwc at csd4.csd.uwm.edu (Greg F Walz
Chojnacki) writes: [in Newsgroups: sci.astro]

 GFWC> I need a FITS image viewer.. tried VFITS012 for OS/2.. hangs
 GFWC> [for] images other than the samples.. how to use VFIT012[?]..
 GFWC> [or] another FITS viewer..?

1) Newsgroup sci.astro.fits exists for the purpose of discussing
FITS-related questions. I have crossposted this followup to s.a.f.

2) AnonFTP directory fits.cv.nrao.edu [192.33.115.8]
/fits/os-support/dos contains the following files related to
FITS-support software for DOS:

               2242 May  5 09:18 ftb30b.mail
               3480 Apr  2 22:34 imagine-32.news
               4211 Dec 31 13:58 imdisp-fits.news
               7399 Oct 15  1992 imdisp77.news
             342084 Oct 15  1992 imdisp77.zip
             131107 Oct 15  1992 imdisp78.exe
               5968 Oct 15  1992 imdisp78.news
               2827 Apr 29 00:27 imdisp78b.news
              19075 Mar  4 08:56 imdisp79.news
               1267 Dec  2  1992 ipsys.news
               6300 Jul 28  1991 listfits.c
               1735 Dec  3  1992 mira.news
               7010 Apr 28 09:26 pcvista.news
                959 Mar 10 07:06 s-and-t.news
               1957 Jun 28 10:59 vfits012.news

I suggest that you look at these files if you have not already done
so. I have appended your posting to the file containing the original
announcement of availability of vfits012.

3) A common weakness of simple FITS software is refusal to handle
cases of (NAXIS != 2) and, in particular, cases of (NAXIS > 2). In
many such cases NAXISi==1 for i>2 and therefore if you have source you
can probably add the support easily.

4) Another common source of trouble is using FTP to copy FITS files
without setting binary mode.
--

  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 Jul  1 20:55:37 1993
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA28433; Thu, 1 Jul 93 20:55:37 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Fri, 2 Jul 1993 00:18:48 GMT
From: mcollins at wdc.sps.mot.com (Michael Collins)
Message-Id: <1993Jul2.001848.4084 at newsgate.sps.mot.com>
Organization: Motorola Western MCU Design Center, Chandler Arizona
Path: cv3.cv.nrao.edu!uvaarpa!caen!math.ohio-state.edu!howland.reston.ans.net!noc.near.net!uunet!spsgate!mogate!newsgate!wdc!mcollins
Subject: Looking for DAOPHOT
Sender: fitsbits-request at fits.CV.NRAO.EDU

  Does anyone know where I could get DAOPHOT as a stand-alone executable
for a Sun 4 running SunOS 4.1.3?  I know this software is part of IRAF,
however, our network configuration prohibits me from installing that
package according to the documentation and I haven't been successful
in my attempts to get a partial, nonstandard installation running.  I
have access to some photometric data which I would like to try my hand
at reducing and DAOPHOT appears to be an appopriate tool for the job.
  Either an ftp site or a source for magnetic media in just about any
format is acceptable.  An executable is highly preferred as we don't
have a FORTRAN compiler.  I'm hoping someone can point me at a file
comparable to one I found on fits.cv.nrao.edu which uncompressed to
a working copy of SAOimage.  I expect DAOPHOT to be bigger and likely
much more complex, but that's the general idea anyway.
  Any assistance will be appreciated.  I'll also be happy to summarize
and report email replies.

				-- Michael Collins --
--
mcollins at wdc.sps.mot.com

From dwells  Fri Jul  2 08:48:08 1993
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA00380; Fri, 2 Jul 93 08:48:08 EDT
Resent-Date: Fri, 2 Jul 1993 10:02:11 +0100
Resent-From: dwells (Don Wells)
Resent-Message-Id: <9307021248.AA00380 at fits.cv.nrao.edu>
Return-Path: <dwells>
Message-Id: <9307021248.AA00374 at fits.cv.nrao.edu>
To: fitsbits
From: pma at rlsvs2.bnsc.rl.ac.uk (Peter M. Allan)
Subject: DAOPHOT
Date: Fri, 2 Jul 1993 10:02:11 +0100
Resent-Sender: dwells
Sender: fitsbits-request at fits.CV.NRAO.EDU

    [mistakenly sent to "fitsbits-request" instead of "fitsbits" -Don]
------- Start of forwarded message -------
From: pma at rlsvs2.bnsc.rl.ac.uk (Peter M. Allan)
To: fitsbits-request at fits.CV.NRAO.EDU
Subject: DAOPHOT
Date: Fri, 2 Jul 1993 10:02:11 +0100

Michael,

We provide DAOPHOT as part of the STARLINK software collection with the
agreement of the author of DAOPHOT. The version that we distribute reads files
that are stored in the Hierarchical Data System (HDS) format. If you do not
have files in this format (I presume that you do not), we can supply you with
software to convert data into HDS files. We do have a version for SunOS 4.1.3.

The documentation that I have about DAOPHOT states that the version at DAO
reads data in Caltech Figaro format. This used to be a bastardised version of
HDS, but Caltech Figaro now uses HDS directly. I am not sure if this has
reached DAO, but it seems likely.

The author of DAOPHOT is Peter Stetson (stetson at dao.nrc.ca). If you want to get
the most up to date version of the code you should go to him. I expect that you
will have to build the system yourself though.

If you want to get DAOPHOT (ready built plus source code) from us, or if you
want any other STARLINK software just let me know.

Peter Allan
STARLINK project
Rutherford Appleton Laboratory
------- End of forwarded message -------