Subject: World Coordinate Systems

From: egreisen at primate.CV.NRAO.EDU (Eric Greisen)
Date: Tue, 10 Nov 92 08:58:54 EST

Bill Thompson writes

 > After having read the world coordinates proposal, I am still unclear as to how
 > the developers would describe this very simple problem:
 > 
 > 	Given: A slit spectrograph with a single pointing position.  The
 > 	dimensions of the data are two: one spatial coordinate and one
 > 	spectral coordinate.  However, to describe the pointing, two
 > 	spatial coordinates are needed, as well as the orientation of
 > 	the slit, and the spectral dispersion and central wavelength.
 > 	In other words, the data has only two dimensions, but it takes
 > 	three dimensions to properly describe it.
 > 
 > Secondly, it appears that this convention is only relevant to skymapped
 > data--which I admit applies to most astronomical data.  However, it's hard to
 > see the relevance to solar images, for example.

The method that has been used since day 1 in FITS is to specify 3 axes with only 1
pixel on the third axis.

I have been disturbed by the title "World Coordinate Systems" given to the
discussions since it implies some global solution to all problems.  The original
FITS paper did not even address this area since it is too vast and too filled 
with matters that raise peoples' blood pressure.  All we are attempting to do
now is to develop a nomenclature for representing various celestial coordinates
including the types of projections used.  We are not going to address the spectral
domain even though that is a domain we all have in common.  It appears that the
solutions used are too diverse - and solutions which I regard as non-scientific
are too widely used and defended - for us to expect much agreement in that area.

William Thompson, code 682.1, x2040 also writes:
 > In the document "World Coordinate Systems Representations Within the FITS
 > Format", it is stated.
 > 
 > {\tt CTYPE1, CTYPE2} -- the type of world coordinate axes.  The {\tt CTYPE}
 > value strings are eight characters in length, and are constructed from
 > two four-character segments.  The first four characters give the type
 > of world coordinate, and the second four characters give the type of
 > projection geometry.  The first four-character string is left-justified
 > and filled out to a length of four characters by appending hyphens; the
 > second four-character string is right-justified and filled out to a length
 > of four characters by prepending hyphens. The following coordinate pairs and
 > geometries are recognized: 
 > 
 > This is a new requirement for this keyword.  I would like to know how software
 > (e.g. AIPS) which is written to parse files written using world coordinates
 > will handle data which does not follow the conventions outlined in the world
 > coordinates document.  This applies both to data written before this convention
 > was devised, and to future data that does not conform to this convention.
 > 

Again, this is intended to be a convention for celestial coordinates primarily,
although it suggests a convention that one might wish to use in other areas.
AIPS will handle any string in CTYPEn, but if that string is not of a recognizable
type then AIPS will assume that the axis is linear in the coordinate, plot it as
such, and label it with the value of the CTYPEn string.  It seems to me that this
is a reasonable compromise since one does have to recognize the type of coordinate
before one can apply any non-linear function to its computation.  For example,
some institutions have written tapes that declare the spatial components to be
"RA" and "DEC" with no special remarks.  AIPS treats them - reasonable I would
argue - as linear in RA, Dec with no cos(dec) terms.  For some non-linear function
to be applied we need to agree on some nomenclature to imply its use.

 > Our plans are to use a unified keyword system for all aspects of the SOHO data,
 > both within FITS files and out.  The values of the CTYPE keyword are supposed
 > to be the names of valid SOHO keywords which represent the physical unit
 > represented by that dimension, e.g.
 > 
 > 	CTYPE1  = 'INS_Y   '		/Instrument Y axis
 > 	CTYPE2  = 'INS_Z   '		/Instrument Z axis
 > 	CTYPE3  = 'WAVELNTH'		/Wavelength
 > 
 > In other instances, depending on the kind of data being gathered, these same
 > names could appear as FITS keywords
 > 
 > 	INS_Y   =          3	/Instrument Y pointing (arcsec)
 > 	INS_Z   =          5	/Instrument Z pointing (arcsec)
 > 	WAVELNTH=     584.60	/Wavelength in Angstroms
 > 

 > There is no way we could live within the restrictions of the world coordinate
 > system as regards the CTYPE keyword.  (Having to live with "WAVELNTH" instead
 > of "WAVELENGTH" is bad enough!)

I applaud the first usage (partly) and deplore the second.  The whole reason for
having very general and defined keywords was to attempt to convey information
between sites (and over time) without having to have special codes for every
2-party connections.  The first usage allows a general program to make some sense
of the information provides, the second usage simply gets dumped to history files
and ignored.  The "(partly)" above is from my guess that you could in fact provide
us with useful celestial coordinate information instead and thereby allow scientists
to compare your imagery with those generated by other instruments.

 > 
 > The goals of the world coordinate system are important and quite laudable.
 > However, the FITS community needs to recognize the existence of data sets that
 > are and will be outside of this convention.  Since our data will have no
 > relationship to the celestial sphere, none of the coordinate systems
 > (geocentric, galactic, or ecliptic) are relevant for our data set.  Will future
 > FITS readers such as AIPS be able to handle data outside of the new world
 > coordinate system convention.
 > 
 > It seems to me that CTYPE is now being asked to serve two functions.  It
 > specifies the physical meaning of the data, as has always been its function.
 > It also is now being asked to specify the kind of data projection used as well,
 > which is a totally new function.  I believe that these should be separated into
 > two separate sets of keywords.  In other words, instead of
 > 
 > 	CTYPE1  = 'DEC--TAN'
 > 
 > you would have
 > 
 > 	CTYPE1  = 'DEC     '
 > 	CPROJ1  = 'TAN     '
 > 
 > This would provide for more flexibility and capatibility with existing systems.
 > Once that change is made, there's no reason why other data sets could be
 > brought into at least *partial* agreement with this convention.

This usage is quite old actually.  It was first described in writing by me in
April 1983 and has been used on the 1000's of VLA images ever since.  It was picked
up and used by many other sites over the years and the draft proposal you have
read was dated in 1988.  I am engaged as we speak in converting the old papers to
LaTeX so that they can be re-released in a modern form.  I intend also to review
the proposal and flesh it out with better details.  The draft proposal is fine for
simple projections.  However, I fear that a good description of more general
coordinates (i.e. Aitoff) will not fit well in the proposal and that the CD....
matrix provides rotation information that would be better provided in another way.
I am not sure about this as yet, but fear that we will end up with 2 rotations, one
of which is in the CD matrix, which could have been given as only one.

Eric Greisen
Scientist
National Radio Astronomy Observatory

---

From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Date: 10 Nov 92 17:31:00 GMT

In article <9211101358.AA01257 at primate.cv.nrao.edu>, egreisen at primate.CV.NRAO.EDU (Eric Greisen) writes...

	(stuff deleted)

>is a reasonable compromise ...

Sounds quite reasonable to me too, and addresses my concerns in this area.

Eric Greisen also writes ...

>to compare your imagery with those generated by other instruments.

Could you clarify what you mean by "first" and "second".  I'm unsure about what
you're getting at here.

In terms of "useful celestial coordinate" information, our plan is to provide
the data in raw units, and in the coordinate system the data was actually taken
in.  The data needed to convert this into useful coordinates and scientific
units will also be included, but not applied.  Our feeling is that the
calibration is a fluid thing, and that our understanding will change over time.
The calibration information stored in the file will probably only represent a
first quess.  We will distribute the calibration data separately, which can be
more easily updated.

Eric Greisen goes on to say ...

>the proposal and flesh it out with better details. ...

By "new", I mean that it is not discussed within the confines of the FITS
standard document.  I'm surprised that you decided to add new functionality
within a pre-existing structure.  Future enhancements to the standard should
avoid this trap.

Bill Thompson

---

From: dbriggs at zia.aoc.nrao.edu (Daniel Briggs)
Date: Wed, 11 Nov 92 11:38:55 GMT

In article <9211101358.AA01257 at primate.cv.nrao.edu>
  egreisen at primate.CV.NRAO.EDU (Eric Greisen) writes:
>The method that has been used since day 1 in FITS is to specify 3 axes with
>only 1 pixel on the third axis.

Yes, but in some situations this has proved an unfortunate choice.  I've
never been happy with the practice of stuffing additional information about
the image into 1 pixel pseudo-axes.  In the case of a spectral instrument,
one might plausibly make the argument that the fundamental data is really
an M x N x 1 cube, but to stuff things like Fourier transform axis
conjugation information in as pseudo-axes is really deplorable.  To make
things more concrete, suppose that I have a set of matrix routines in my
favorite imaging package, and that I'd like it to operate on the arbitrary
contents of a FITS image.  In such a case, it really does make a difference
whether there are 1 or 2 "real" dimensions.  Is it a one dimensional image
that should be treated as a vector, (but with some number of pseudo axes
following it), or is it a two dimensional image that merely happens to have
one pixel in the second dimension?  As it stands now, there is really no
way to tell, without building in a list of recognized axis types.  I've
always felt that in an ideal world NAXIS would represent the true
dimensionality of the data, not simply the number of entries in the
coordinate arrays.  Or perhaps the other way around, and we could have an
RNAXIS keyword to hold the real number of axes.  It's not a major problem,
and I'm not seriously suggesting the above as a fix, but in a few cases I
have had to make some real kludges to get around this problem.

-- 
| Daniel Briggs  (dbriggs at nrao.edu)                      |  USPA B-14993
| New Mexico Tech / National Radio Astronomy Observatory |      DoD #387
| P.O. Box O / Socorro, NM 87801   (505) 835-7391        | 
Support the League for Programming Freedom   (info from lpf at uunet.uu.net)