[fitswcs] Comments on Paper III

[Jonathan McDowell]

Comments on WCS Paper 3
-----------------------

At Bill Pence's urging, I have finally studied the current version of
WCS-3 in detail. Apologies for getting to it so late. I mostly like the
new version of the paper, and I think the basic handling of spectra is
fine, but I have real reservations about the implementation of the LOG and
TAB transforms and some lingering doubts about things like AWAV.

(A) Typographical and other nits:

Page 2 - spelling error for 'negligible'.

Page 3. para 1: the statement "the fifth character is '-'"
could be misinterpreted to mean that in the case of linear
axes, it's CTYPE = "FREQ-  " instead of just "FREQ  "
In the second para you do say for this case "the last
four .. shall be blank", but since you have not emphasized
that the total is 8, this would be better phrased
"characters five through eight shall be blank".

(B) Lingering doubts

The current CTYPE-first-four values

FREQ;  ENER;  WAVN; WAVE, AWAV; VRAD, VOPT, ZOPT, BETA, VELO

do not bring out the key fact that WAVE and AWAV are basically the same
thing but different from FREQ; similarly VRAD, VOPT, VELO are closer to
each other than they are to FREQ - in the pragmatic sense that
applications programs are likely to care more often about whether the
spectrum is WAVE or FREQ than whether it is WAVE or AWAV. Isn't the WAVE
vs AWAV distinction more like the kind of distinction covered by
SPECSYS? Why have SPECSYS rather than CTYPE keys WTOPO, WBARY, etc...?
... well I know why, but I would argue the WAVE/AWAVE distinction should
be in another keyword, not in CTYPE. (Aside: If Paper 2 provided a way
to distinguish between RA, DEC positions which have/have not been
corrected for atmospheric refraction, I'm missing it.)


(C) LOG

I am uncomfortable with the definition of -LOG. The equation S = Sr exp(
w/Sr ) is indeed pretty, and its expansion to S ~ Sr + w a nice touch,
but at the cost of being very unnatural to astronomers. Can you adduce
any examples of astronomical data in which the coordinate systems are
described using natural logarithms? 

I suggest there is a subtle conceptual difference between an axis with
logarithmic steps and a world coordinate of frequency, and an axis with
linear steps (in log frequency) in which the world coordinate is the
log of the frequency (which latter tends to be the mindset in spectral
energy distribution work).

In non-spectral cases with logarithmic axes, too, I believe
that most astronomers would prefer to interpret CDELTn
as the base 10 logarithmic step:
  S = Sr . 10 ** w
Then looking at the value of CDELT in the header would
immediately make sense to the user, I feel. 
For example, compare
  CTYPE1='FLUX-LOG'
  CRVAL1=    5500.0
  CUNIT1=     'Jy'
  CRPIX1=       0.0
  CDELT1=      -0.4   /  Logarithmic step
with
  CDELT1=  -5065.7    /  -0.4 ln 10 * CRVAL1

The first case is instantly recognizable to optical astronomers
as meaning the pixel axis is in magnitudes. The second
case is obscure. I think that losing the 'derivative is one
at the ref point' is a legitimate concern of elegance, but
should be trumped by user-friendliness.
	

(B) TAB

I like the idea of the TAB transform. However I wonder if
this fundamental addition to FITS should be in yet a
separate paper.

Why the horizontal (1 row, array column) arrangement? For the simple
case (separable 1D axes) a vertical (many rows, scalar column)
arrangement seems much more natural and allows many existing calibration
lookup files to be used without change. You could then go to a 1D array
per cell for the 2D case, and so on, perhaps not as elegant then for the
higher dimensional cases - but these are rare!

I understand that some concern was expressed that a vertically
arranged table might be mis-sorted by the user. I think that's only
a greater danger for vertical than horizontal tables because
more software currently exists to deal with them, and implementation
of the proposed convention will change that.

I find the use of PS.. and PV... keywords to be obscure. I think for
this usage more explicit keywords like say CTBEXTn, CTBCOLn, CTBIDXn
or something of the kind would be easier to deal with. I guess PS and PV
are proposed as general WCS parameters, but -TAB is a pretty special case.


 - Jonathan McDowell