Subject: Comments on OGIP on proposal for RA/Dec keywords

From: mo at cfa234.harvard.edu (Maureen Conroy)
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: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Mon, 21 Jun 93 17:31:19 EDT

>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: forveill at gag.observ-gr.fr (Thierry Forveille)
Date: Tue, 22 Jun 1993 15:45:08 +0200

> 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?

 > just to read these keywords than it is to perform the complicated
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.

 > 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: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Tue, 22 Jun 93 12:25:12 EDT

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: arots at xebec.gsfc.nasa.gov (Arnold Rots)
Date: Wed, 23 Jun 93 08:34:58 EDT

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