[fitswcs] Keywords for other FITS image representations

[Mark Calabretta]

On Thu 1998/08/06 11:23:56 -0400, William Pence wrote
in a message to: fitswcs at fits.cv.nrao.edu

>Keyword               Primary      BINTABLE      Table   
>Description           Array         Vector      Pixel List
>------------          -------      --------    ----------
> Axis Type            CTYPEiiv     iCTYnnnv    TCTYPnnn
>                                               TCTYnnnv
> Axis Units           CUNITiiv     iCUNnnnv    TCUNInnn
>                                               TCUNnnnv
> Reference Pixel      CRPIXiiv     iCRPnnnv    TCRPXnnn
>                                               TCRPnnnv  
> Reference Value      CRVALiiv     iCRVnnnv    TCRVLnnn
>                                               TCRVnnnv   
> Pixel Increment      CDELTiiv     iCDLnnnv    TCDLTnnn
>                                               TCDLnnnv   
> Axis Rotation        CROTAiiv     iCROnnnv    TCROTnnn
>                                               TCROnnnv   
> Rotation Matrix      CDii_jjv     ijCDnnnv    TCDnn_mm
>                                               TCnn_mmv
> Coord. Rotation      LONGPOLE     LONGnnnv    LONGnnnv 
>                      LONPOLEv
> Coord. Rotation      LATPOLEv     LATnnnv     LATPnnnv    
> Proj. Param.         PROJPkv      kPROnnnv    kPROnnnv      
> Coord. Epoch         EQUINOXv     EQUInnnv    EQUInnnv     
> MJD of Obs.          MJD-OBSv     MJDOnnnv    MJDOnnnv 
> Reference Frame      RADECSYS     RADEnnnv    RADEnnnv 
>                      RADESYSv
>
>i,j  = axis numbers,  1 - 9 or 1 - 99
>k    = projection parmeter number, 1 - 9
>n,m  = table column numbers, 1 - 999
>v    = version code, blank or A - Z

Since we now allow projections to be associated with multiple axes we have to
generalize the auxiliary parameters LONGPOLE, LATPOLE, EQUINOX, RADECSYS, and
MJD-OBS to include an axis number as well as a version number.

First, I propose changing Eric's CPii_kkv (in the current indexing notation)
slightly to PVkk_iiv so that the parameter number "kk" becomes part of the
"name" part of the keyword, leaving the axis and version as part of the
keyword's "qualifier".  CP is changed to PV (parameter value) so that the
first letter differs from that of the CD matrix; the reason for this will
become clear shortly.

Consider the following scheme:

   Primary:  PVkk_iiv  LNGPLiiv  LATPLiiv  EQNOXiiv  EQSYSiiv  MJDOBiiv

  Bintable:  Pkkiivnn  LNGiivnn  LATiivnn  EQNiivnn  EQSiivnn  MJDiivnn
         or  Pkkivnnn  LNGivnnn  LATivnnn  EQNivnnn  EQSivnnn  MJDivnnn

   Pixlist:  PVkknnnv  LNGPnnnv  LATPnnnv  EQNOnnnv  EQSYnnnv  MJDOnnnv

The pattern here should be fairly easy for humans and software to interpret.
The "v" being alphabetical and non-optional for bintable serves as a useful
delimiter and allows variants between the "iivnn" and "ivnnn" forms thereby
allowing writers the opportunity to judiciously organize the table so that
images with up to 99 axes can be supported in columns 1-99.  In order to
disambiguate "Pkkivnnn" from "Pkiivnnn" we have to make a rule that the "kk"
in "Pkk..." always consists of two digits, i.e. with leading zero as
appropriate.  Similarly for the pixlist PVkknnnv.  This should therefore be
extended to the PVkk_iiv for consistency.

If there are no backwards compatibility issues I would also extend this scheme
to the remaining keywords:

   Primary:  CTYPEiiv  CUNITiiv  CRPIXiiv  CRVALiiv  CDii_jjv

  Bintable:  CTYiivnn  CUNiivnn  CRPiivnn  CRViivnn  Ciijjvnn
         or  CTYivnnn  CUNivnnn  CRPivnnn  CRVivnnn  Cijvnnn

   Pixlist:  TCTYnnnv  TCUNnnnv  TCRPnnnv  TCRVnnnv  CDnn_mmv  (for backwards
                                                                compatibility)
If not for backwards compatibility I would have written

   Pixlist:  CTYPnnnv  CUNInnnv  CRPInnnv  CRVAnnnv  CDnn_mmv

To disambiguate Ciijvnnn and Cijjvnnn we have to introduce a rule that if i is
doubled then so must j be, and vice versa.  This allows images with up to 99
axes to appear in columns 1-99.

Presumably CROTAn and CDELTn should not appear in the list, else their form
should be obvious.

If not too much of a shock to the system I suggest the "v" version letter be
lower-case to distinguish it from the fixed part of the keyword.  Gasp!


Cheers, Mark