[fitswcs] WCS documents

[Eric Greisen]

Stephen Walton writes:
 > I cannot pretend to speak for everyone, but my quietude has been at least
 > in part to incomplete understanding of all the issues involved.  I am
 > curious about the current discussion:  I _think_ it is in response to the
 > IRAF group's suggestion (quoting from their Web site): "we propose that
 > the WCS dimension be given by the highest value of the axis in any CTYPE
 > keyword, and that this value be permitted to be greater than the value of
 > NAXIS (a WCSDIM keyword could also be added to make this distinction more
 > apparent, but this is not necessary)."  As I understand it, this is to
 > allow subimages to carry along WCS information correctly.

     Actually this 1-pixel axis business is a triviality.  The
original FITS papers contained 1 pixel axes used to convey coordinate
information and they have been in use ever since.  The radio community
can live with the optical convention of throwing away 1 pixel axes as
array axes although the meaning of CRPIX is curious if there are no
pixels on a coordinate "axis" which is not an axis of the array.
Furthermore, in many cases such as your example below, the CRPIX is
likely to be -5.5 which implies multiple pixels on the non existent
axis.  The need for a CDi_j also implies an increment in coordinate on
this semi non-existent axis.  You see why I have trouble with the NOAO
concept.  The radio community will simply default NAXISm to 1 and
substitute WCSNAXES for NAXIS.  I do not care for that since it means
that we are really using NAXIS solely for the purpose of saying how
many NAXISm words follow in their required locations and we are then
using > 1 keyword to convey the information one keyword could convey.

The far greater issues involve how observations with complex
instruments are converted into meaningful coordinates.  The NOAO
proposal mostly deals with that issue and was extremely helpful in
that regard.

 > 
 > I am afraid I don't get this.  If I have a 15 by 17 by 12 spatial by
 > spectral by spatial image, let's say, and I copy the portion
 > [1:15,11,1:12] to another image, most software I know of would create a 15
 > by 12 image as output, not a 15 by 1 by 12 image.  If said software also

    Why not 15 x 1 x 12?  It is perfectly legitimate as a matrix
representation?  It avoids the coordinate confusion you then assume
(below) one would fall into.  It allows for easy transposition to 
15 x 12 x 1 if that feels better (transposing all of the coordinate
words as one would always do in a transposition).  There are major
packages that do not make the mistakes you assume they will.

 > simply copied the WCS with no checking, then there would be a mismatch;
 > further processing would associate the second WCS component of the
 > original image with the second dimension of the new image, rather than
 > with the third.  I can't see how the proposal quoted above, with or
 > without a WCSDIM/WCSAXES keyword, would help.
 > 
 > Bob, would you care to elaborate on some of the practical problems viz a
 > viz 'radio-optical interoperability' you ran into recently?
 > 
 > Steve

As FITS usage grows, there will be many examples where one package
will use a new concept (or an old one in the case of 1 pixel axes)
which some, perhaps short-sighted, package does not expect.  What
keeps us software people employed is correcting our oversights and
other errors.  FITS is a *transport* system and one MUST expect to
have to do at least some translation when moving into and out of an
internal format.  That is why I say our software can live with the
NOAO proposal even though I believe it to be misguided.  Some software
is known to break when reading our 4 dimensional images even though 2
of the axes often, but not always, have only 1 pixel on them.

Eric Greisen