[fitswcs] Status of WCS negotiations

[Eric Greisen]

Don Wells writes:

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

     I tend to agree with Don on most of this.  The chance to absorb
the IRAF data (or at least portion of it with full WCS in headers) is
a good thing and AIPS has to change in any case.  I oppose limiting
the number of axes to 9 since AIPS gets close to that in some cases.
Remember that 1-point axes are an easy and correct way to convey
coordinate information - AIPS images routinely have a 1-point axis for
frequency and for Stokes and really should (but don't) for time.  Of
course all these axes can be > 1 point for e.g. spectral-line cubes,
polarization imagery, or time series.

     Don's use of the PROJPn keyword makes the point that we need a
better keyword for this purpose.  I propose CPnn_iiV where CP means
coordinate parameter, nn (1 or 2 digit no leading zero) is the axis
number, ii (1 or 2 digits no leading zero) is the parameter number and
V is the version code (blank for main, A-Z for secondary
descriptions).  This general word allows us to propose projection-like
parameters for e.g. velocity axes in some future agreement.  For axis
pairs (longitude-latitude) we will have to agree on which axis is
given the CPs and I would suggest the latitude (in honor of the by now
much deprecated CROTA2).  The omission of leading zeros (forcing the _
separator) is in line with the NOST standard as is the limit to
upper-case letters in the version code.

 > 
 > We could decide that values of the main WCS keywords (CD2_1, CTYPE3,
 > CRVAL1, CRPIX2) would be used for each alternative WCS unless
 > overridden. This would produce smaller headers in many cases, but
 > would mean that if PROJP13 is set in the main WCS but isn't used in
 > alternative WCS C it would have to be explicitly reset with
 > PROJP13C=0. I would prefer to duplicate everything, because it would
 > simplify the text of the agreement and would be less likely to cause
 > implementation errors. The usual defaults should apply (1 on diagonal,
 > 0 off diagonal for CDi_jm, 0 for PROJPim).

     Dumb software can be used to swap descriptions en mass.  Any
other convention requires smart software which we all know to be
problematical.  Besides, if I start with a simple cube in which
velocity/frequency is orthogonal to latitude-longitude (which would
allow the more complex defaulting) and decide to rotate it in a
3-space to view it from some other angles, then I will have to give
all the coordinates and parameters anyway.  So why not in the simple
case as well?

 > 
 >  > Hanish & Wells (1988) suggested writing CDELTn and CROTAn
 >  > together with the CD matrix for the benefit of old interpreters.  Is that
 >  > still a good idea?  
 > 
 > Certainly reasonable people can differ on this question. I have
 > changed my mind---I now think it will be better not to put CROTA2 in
 > the header along with CDi_j, but instead to provide standalone
 > conversion program(s) to translate headers for forward/backward
 > compatibility. My bet is that almost all of the old interpreters are
 > going to disappear quickly soon after we reach this agreement.

I think writing these parameters - given the immense confusion that
they seem to engender - is probably a bad idea.  The paper should have
conversion formulae (nothing much wrong with what's there now I think)
but it will be best to stop CROTA's asap.  BTW - the interpreters will
have to read the old notation forever (more or less) and it will be
years before users replace their old copies of IRAF or AIPS even if
those mammoth packages could be updated over night.  (I am continually
amazed at the antiquity of AIPS versions that active AIPS sites are
using!)

I stand ready to do the work of a re-write of the papers along lines
that have been proposed.  But I am willing to do that work only if I
think there is a reasonable chance that what comes out will gain
sufficient acceptance to move forward as a standard.  I am far too
busy keeping AIPS afloat and moving forward while AIPS++ does whatever
it is doing to waste time re-writing a lengthy document just to
receive more of the disapproving but mostly silent response engendered
by the current one.

Eric Greisen