[fitsbits] Proposed Changes to the FITS Standard

[Mark Calabretta]

On Mon 2007/07/23 15:03:43 -0400, William Pence wrote
in a message to: FITSBITS <fitsbits at nrao.edu>

>Please post any comments, suggestions, or concerns regarding these 
>proposals (or any other suggestions for improving the Standard document) 
>here on the FITSBITS email list, or on the associated sci.astro.fits 

Sect. 8 looks like a very competent summary with plenty of evidence of
careful work, well done Dick!  The following comments are all minor:

* In Table 8.1 and elsewhere the 'a' symbol used for the alternate code
  should be in math font.

* p82: where CROTA2 is mentioned it should be stated in this context
  that, while it may occur with CDi_ja, it must not occur with PCi_ja.

* Table 8.2: it would be better if RESTFREQ was presented in the same
  way as RADECSYS.  A footnote describing these forms would be useful.

* The note at the bottom of Table 8.2 reverses the meaning of i and j.
  In that note, k also refers to column number in a pixel list.

* p86: There are a number of keywords, ijPCna, ijCDna, iVn_ma, and so
  on, where 'a' could be pushed right out of the 8-char keyword name
  for plausible values of i, j, k, n, and m.  In such cases 'a' is still
  said to be "blank" although it is not the blank character.  (This
  isn't really made clear in Paper I.)

* p87: probably should indicate that no time system (UTC, TAI, TCB,
  etc.) is currently defined for MJD-OBS or any of the other time-
  related keywords.  (This is not important for anything in the
  existing WCS papers.)

* p90: "Vaccuum"

* p91: the footnote mark doesn't appear anywhere in the table or
  caption.

* p92: the reference to Table 8.6 should be 8.7.

* p92: the discussion at the bottom should indicate that the diurnal
  Doppler correction is only weakly dependent on position and therefore
  great accuracy is not required.

* p93 footnote: how could CUNITia (not CUNITka) substitute for VELOSYSa
  anyway?  Or should the footnote really refer to the units of VELOSYSa
  specified later?

* p93: in the description of ZSOURCEa, the reference to ZSOURCEa should
  be SSYSSRCa.

General note: there are a few anomalies in the set of WCS keywords as
published.  The main one is that no bintable or pixel list equivalent
of DATE-OBS is defined.  Also, the pixel list form for WCSNAMEa was
mistakenly specified as TWCSna instead of WCSNna.  I can do no better
than to append an extract of the usage notes for the WCSLIB 4.3 function
wcshdo() (as yet unreleased) which writes out a WCS data structure as
a FITS header.  This might be a good opportunity to legitimise these
extended usages - I note that Table 8.2 has already captured WCSHDO_TPC
and WCSHDO_PV from the errata.

Mark Calabretta
ATNF

>>>

*    8) wcshdo() interprets the "relax" argument as a vector of flag bits to
*       provide fine-grained control over what non-standard WCS cards to
*       write.  The flag bits are subject to change in future and should be
*       set by using the preprocessor macros defined below for the purpose.
*
*         WCSHDO_none: Don't use any extensions.
*
*         WCSHDO_all: Write all recognized extensions, equivalent to setting
*               each flag bit.
*
*         WCSHDO_safe: Write all extensions that are considered to be safe and
*               recommended.
*
*         WCSHDO_DOBS: Write DOBSn, the column-specific analogue of DATE-OBS
*               for use in binary tables and pixel lists.  WCS Paper III
*               introduced DATE-AVG and DAVGn but by an oversight DOBSn (the
*               obvious analogy) was never formally defined by the standard. 
*               The alternative to using DOBSn is to write DATE-OBS which
*               applies to the whole table.  This usage is considered to be
*               safe and is recommended.
*
*         WCSHDO_TPC: Paper I defined
*
*                 TPn_ka and TCn_ka for pixel lists
*
*               but Paper II uses TPCn_ka in one example and subsequently the
*               errata for the WCS papers legitimized the use of
*
*                 TPCn_ka and TCDn_ka for pixel lists
*
*               provided that the keyword does not exceed eight characters.
*               This usage is considered to be safe and is recommended because
*               of the non-mnemonic terseness of the shorter forms.
*
*         WCSHDO_PV: Paper I defined
*
*                 iVn_ma and iSn_ma for bintables and
*                 TVn_ma and TSn_ma for pixel lists
*
*               but Paper II uses iPVn_ma and TPVn_ma in the examples and
*               subsequently the errata for the WCS papers legitimized the
*               use of
*
*                 iPVn_ma and iPSn_ma for bintables and
*                 TPVn_ma and TPSn_ma for pixel lists
*
*               provided that the keyword does not exceed eight characters.
*               This usage is considered to be safe and is recommended because
*               of the non-mnemonic terseness of the shorter forms.
*
*         WCSHDO_CRPX: For historical reasons Paper I defined
*
*                 jCRPXn, iCDLTn, iCRVLn, iCUNIn, and iCTYPn for bintables and
*                 TCRPXn, TCDLTn, TCRVLn, TCUNIn, and TCTYPn for pixel lists
*
*               for use without an alternate version specifier.  However,
*               subject to the eight-character keyword constraint, in order to
*               accommodate column numbers greater than 99 it also defined
*
*                 jCRPna, iCDEna, iCRVna, iCUNna, and iCTYna for bintables and
*                 TCRPna, TCDEna, TCRVna, TCUNna, and TCTYna for pixel lists
*
*               for use with an alternate version specifier (the 'a').  Like
*               the PC, CD, PV, and PS keywords there is an obvious tendency
*               to confuse these two forms for column numbers up to 99.  It
*               is very unlikely that a parser would reject keywords in the
*               first set with a non-blank alternate version specifier so this
*               usage is considered to be safe and is recommended.
*
*         WCSHDO_CNAM: Papers I and III defined
*
*                 iCNAna,  iCRDna,  and iCSYna  for bintables and
*                 TCNAna,  TCRDna,  and TCSYna  for pixel lists
*
*               By analogy with the above the long forms would be
*
*                 iCNAMna, iCRDEna, and iCSYEna for bintables and
*                 TCNAMna, TCRDEna, and TCSYEna for pixel lists
*
*               This usage is potentially unsafe and is not recommended at
*               this time.
*
*         WCSHDO_WCSN: Paper I mistakenly defined the pixel list form of
*               WCSNAMEa as TWCSna instead of WCSNna; the 'T' is meant to
*               substitute for the axis number in the binary table form of the
*               keyword - note that keywords defined in Papers II and III that
*               are not parameterised by axis number have identical forms for
*               binary tables and pixel lists.  This usage is potentially
*               unsafe and is not recommended at this time.