🚀 go-pugleaf

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