[fitswcs] Status of WCS negotiations

[Mark Calabretta]

On Wed 1998/07/15 14:36:27 -0400, Don Wells wrote
in a message to: fitswcs at fits.cv.nrao.edu

>(2) MULTIPLE-WCS: It appears to me that there is a requirement to
>support multiple WCS descriptions of the same data object. I recommend
>that we do this by appending a character code [A-Z] to the WCS
>keywords for secondary descriptions; the keywords without the
>character would be the default operational ones. This notation would
>require reducing the number of axes supported by the WCS keywords from
>999 to 99. If any of you have alternative ideas for multiple-WCS,
>please post them to 'fitswcs'; if you support my suggestion, post
>about that. If the people on this mailing list could agree on this
>notational convention, my bet is that the rest of the FITS community
>would agree too.
>
>(3) CD-MATRIX: I perceive that there exists a substantial consensus
>that the lowest level linear transformation should be done with a
>matrix of partial derivatives, of the sort called 'CD' in current
>implementations. As far as I am aware, there is no longer a
>science-driven requirement for the CDELTi/PCij notation which was
>proposed in the G&C draft.  (I myself have always favored the latter,
>out of feelings of nostalgia for CDELTi and of elegance regarding the
>dimensionless PCij matrix, but I acknowledge that CDij works and has
>an advantage of simplicity.)  I would very much like to see this old
>debate brought to a consensus conclusion so that we could get on with
>the process of revising G&C as discussed above. If there are any
>dissenters from the consensus which I perceive, I ask them to Email me
>privately.

These two are closely related.  First, I think (and I think Eric agrees if he
didn't actually suggest it first) that we need to generalize the PROJPn:

   1) Generalize the name since parameters will be needed for non-celestial,
      non-linear axis types.

   2) Allow more parameters; we thought 100 would be enough even for plate
      solutions like DSS.

   3) Allow parameters to be associated with particular axes.  At the moment
      the association of the PROJPn to the relevant axes is implied by their
      celestial axis types - this also means that we can only have one
      celestial plane per HDU. 

   4) Support multiple representations per axis.

The conclusion was to generalize the PROJPn to WCmiijjj, with jjj being the
axis number, ii the parameter number, and m the representation number; we
already have multiple CmVALjjj, CmPIXjjj, CmELTjjj, CmYPEjjj, and CmNITjjj.
The exact names used are negotiable.  BINTABLE and PIXEL LIST forms of these
were provided in G&C table 8 by Pence, Rots & Angelini with the limitation of
only supporting up to 9 image axes.  We also need to embrace multiple LONGPOLE
and LATPOLE.

G&C does not support multiple linear transformation matrices, mainly on the
grounds of parsimony.  We took the view that the PC matrix would be used for a
one-time correction for instrumental setup, i.e. a simple rotation or affine
transformation introduced, say, by misorienting a photographic plate or CCD
array, or reorienting a long-slit spectrogram.  The only arguments I have
heard for multiple linear transformations have been related to storing
multiple plate solutions but in this case the plate solution projection type
(for example the DSS type I described previously) already handles the linear
transformation.  In fact, the main component of the DSS plate solutions are
the scale and a simple rotation - an unsurprising misalignment of the plate
and/or the plate holder.  The single PC matrix has a number of virtues:

   1) Less complexity for FITS readers to deal with.
   2) Dimensionless elements make it conceptually cleaner.
   3) CDELTn allows for easy change of units/scale.
   4) Old FITS files look like new ones with a default PC matrix.
   5) New FITS files without a PC matrix look just like old ones.

The CD matrix formulation (which is recognized in G&C for previous usage) has
a number of disadvantages, allowing multiple CDs just compounds them:

   1) The CD matrix formulation sits uncomfortably with CDELTn.
   2) CD matrix elements have implied units.  Off-diagonal elements may have
      physically meaningless units.
   3) Readers and processing software have to recognize and provide for many
      matrices of size up to 999*999 (4 Mbyte).
   4) Processing software has to match CD matrix representation m with the
      corresponding CmVALjjj, CmPIXjjj, CmYPEjjj, and CmNITjjj.  If any of
      these are missing the representation is invalid.
   5) Multiple representations require many more header cards.  For example,
      to represent a change of units on just one axis requires a whole new
      matrix.
   6) Rescaling one axis requires matrix row multiplication.

The CD matrix also violates the spirit of G&C which defines transformations as
steps in a chain rather than clumping them into an inscrutible monolith.  By
allowing access to the intermediate products of the calculation the CDELTn/PC
formulation may have interesting and unexpected benefits such as the PLON/PLAT
coordinate system that I described on sci.astro.fits (appended).

It boils down to a cost/benefit analysis, not introducing complexity where
it's not needed.  The high degree of flexibility sought comes at significant
expense and while it is of concern to only a small fraction of the FITS-using
community it will be imposed on everyone.  Even so, if someone can show me
just one legitimate example of where it's necessary to maintain multiple
linear transformations then I will reconsider.

Mark Calabretta

>>>

To: fitsbits at fits.cv.nrao.edu
Subject: PLON/PLAT
Date: Fri, 20 Dec 1996 14:51:32 +1100
From: Mark Calabretta <mcalabre at grus.atnf.CSIRO.AU>


Recent discussion on sci.astro.fits has indicated that it would be useful to
formally recognize a PLON/PLAT coordinate system in WCS.

While WCS was developed primarily for mapping the celestial sphere it is also
well suited for other forms of cartography.  The particular requirement which
PLON/PLAT would address is that of describing off-limb phenomena in planetary,
solar, lunar, etc. mapping.

An image using PLON/PLAT coordinates for longitude and latitude on the sphere
would have an implied Cartesian coordinate system which would apply to all
pixels in the image, including those beyond the limb of the sphere.  Secondary
axis descriptors could optionally be used to define a scale and coordinate
type for this Cartesian system.

Note that PLON/PLAT is simply an application of the methods already defined in
the WCS draft using the xLON/xLAT provision.  The proposal here is effectively
to register the name of this application; it does not constitute a fundamental
change to WCS (for example, it won't require a change to WCSLIB).

Examples of usage:

   a) Solar prominences.
   b) Volcanic plumes on Io.
   c) Terrestrial aurorae.
   d) Mapping of the positions of a planet's moons, rings, impacting comets,
      magnetic fields, radiation belts, spacecraft trajectories, etc. in
      relation to its disk.

PLON/PLAT would have the following defining characteristics:
 
   1) Used mainly in conjunction with the azimuthal perspective projection,
      AZP (with mu << -1), for planetary/solar mapping.
 
   2a) The PC matrix is chosen so that the perimeter of the sphere has unit
      radius.

   2b) The map is oriented so that the north pole is at x' = 0, y' >= 0, where
      x' and y' are the coordinate elements corresponding to the PLON and PLAT
      axes obtained after applying the PC matrix to a pixel coordinate.

   2c) The CDELTn header cards scale (x',y') to (x,y) in the "degree" units
      required by WCS.  Their signs are set to invert the native longitude as
      appropriate for a sphere observed from the outside as opposed to the
      usual case of the celestial sphere observed from the inside.
 
   3) Secondary axis descriptors can be used to assign physical units in a
      complementary Cartesian coordinate system for all points in the image,
      including those beyond the perimeter of the sphere.


Mark Calabretta
ATNF