[fitswcs] Status of WCS negotiations

[Doug Tody]

Hi folks -

I apologize for not contributing to this discussion until now.  It happened
to coincide with my summer vacation, and I just got back this week.

I haven't had time to review all that has been said yet.  Scanning it
however, I am impressed with and encouraged by the progress which has been
made!  We will try to review things more carefully here and provide more
detailed comments later this month (probably next week).  Given all the
progress that has been made I am hopeful that we can have most of the details
for a new draft agreement worked out by the end of the month.  We really need
to be able to report major progress on this by the time of the next ADASS
meeting.

For now I will comment only on the following issue which Don raised:

On Wed, 5 Aug 1998, Don Wells wrote:
> It appears to me that the semantics of the CDij notation that we are
> discussing are identical to the semantics used in IRAF (Doug please
> confirm). If that is so, then the agreement should specify the keyword
> style that IRAF uses, because that decision would make several massive
> archives compatible with the agreement and would enable a variety of
> existing FITS reading software to read the agreed notation
> immediately, without any changes.
> 
> I recommend appending the WCS version code, e.g. CD2_1B, CTYPE3D,
> CRVAL1C, CRPIX2A, rather than embedding it. It appears to me that this
> would simplify the pattern matching logic in readers and be easier to
> document in the agreement. In principle we could adopt a variation on
> the HST notation (CD1_1_2 gives the partial of the right ascension
> w.r.t. x for the second CCD in WFPC2 headers), because we will almost
> always have NAXISi<=9 and because we could use [A-Z0-9] to get up to
> 36 versions.  However I am nervous about a limit of 9 for NAXISi, and
> would prefer a limit of 99. The worst cases CRPIX99Z, CRVAL99Z,
> CD99_99Z, CTYPE99Z, PROJP99Z all fit into eight characters, so I
> recommend we go with that.

IRAF usage of the CD matrix is of the form CDi_j.  The matrix defaults to the
identity matrix and zero values are not written to the header, nor required
upon input.  So far as I know all existing IRAF-related data is written in
this form, using the underscore representation (there are cases such as HST
data where additional characters are appended, as is noted above).  The
CDIIIJJJ notation has never been used.

IRAF currently imposes a limit of naxis=9.  So far as I know we have never
come close to exceeding this limit.  Although one can imagine cases where the
dimension is pushed up (due to point axes or whatever), I suspect there are
other less troublesome ways to represent such data.

We use WCS attributes with our data, indexed by axis.  There are cases where
these have run to hundreds of FITS cards (for example if one is encoding a
sampled WCS axis or storing spline coefficients as axis attributes).  So our
experience has been that one digit is enough for the axis number, but three
are needed for data such as WCS axis attributes which can consume many
cards.  In cases where one has an axis number, version (multi-WCS) number,
and running card index (iii), this leaves only 3 characters for the keyword
name or any punctuation such as underscore.

In our usage if both the CD matrix and CROTA are present in a header the CD
matrix takes precedence.  Likewise for the CD matrix and the CDELTi.  CROTA
is recognized only for input, we don't write it to new images.  When WCS was
first implemented in IRAF we wrote out only the CD matrix to new images, but
we were quickly forced to write out the CDELTi as well, as many old programs
require this for scaling purposes.

	- Doug