[fitswcs] WCS Paper III approved

[Malcolm J. Currie]

There are many sensible comments from the IAU-FWG.

The most important is the complexity of the paper impacting the adoption
of the standard and its implementation.  I for one read the opening
pages many times but only comparatively recently made it through to the
end in a single session to comment.

If we can't generate a user guide to FITS WCS post Paper IV (or update
the NOST User's Guide) through lack of financial support---and certainly
astronomical computing is going through bad patch---could we at least
have a webpage where we can contribute our own validated examples along
with descriptions/links to the instruments the headers are describing.


> I realise I am reacting rather late, but I find that the multi-dimensional
> -TAB does not really belong with the rest of the paper. It is undoubtly
> useful, but it has very little to do with spectral coordinates. If it were
> a simple  addition I would not worry about that, but by itself it is
> responsible for  about half the complexity of the paper which is not
> simple.

Is this a question over the implementation, or the need for such a
facility, or the fact that it was postponed and should have appeared in
Paper I?  I think it's the last but if it's the second, I disagree.

Optical astronomers have been using this concept for years, being
especially important for pre-scrunched data.  IRAF has its own
conventions using the ordinary headers.  In Starlink NDF we had an
optional AXIS structure containing (amongst other things) an array of
the axis values for each pixel, and Figaro even had a 2-d axis
structure.  There has been a singular lack of a standard for storing
so-called axis information, so for data interchange a linear wavelength
scale was needed.  X-ray astronomers wanted AXIS information too along
with bounds or widths for their spectra.  While the axis array was used
for imaging too, most 2-d data were on a regular grid, and wasn't as
important as its application to spectroscopy.  [Sky co-ordinates weren't
stored in AXIS arrays.]  So I'd advocate that there is a historical
connexion with spectral co-ordinates.  Astronomers with data having
non-linear axes are most likely to be spectroscopists and hence expect
to consult Paper III first to learn how to export those co-ordinate
arrays in FITS.

Also there was an impetus to get Paper I out of the door after its
long gestation period, although we were fully aware of the need for
storing a list of co-ordinates.

> For spectra however my expectations where different. I'm inclined to make
> a stronger distinction between "raw" data (the IMAGE on the focal plane of
> a spectrometer, for the few cases where I had direct experience, limited
> essentially to old IUE low dispersion spectra, and to VIMOS multi-object
> spectra) and "reduced" data (essentially a - calibrated - spectrum seen as
> a TABLE with flux vs energy - or frequency or wavelength).  OK ... the
> table could also be a 1-d image, but anyhow I'd expected it to be a
> reprojection and rebinning and reprocessing of the raw data.

We know that the standard can't handle many raw formats, e.g.
objective-prism spectra, but it can handle some.  I don't think we
should ignore the latter because of the former.

The above also seems to ignore spectral cubes.

> I see in such respect no reference at all e.g. to high-energy count or
> photon spectra  ... even from
> the trivial fact that customary "keV" are missing as "preferred" energy
> units in Tab. 1.

keV is not SI.  J is.   keV can still be used.

> Another (partially related) issue I did not see (and I could have
> expected), is handling of "error bars" or "large bins" .... think of the
> lower and upper channel boundaries in a photon spectrum and the way to
> properly convert them from dN/dE to FE, Fnu or Flambda, also using a
> spectral model. But the same may apply to any "broad band" spectra (either
> rebinned or simply derived from photometric points).

I've asked for this too.  In our NDF we have optional arrays to store
the variance in the axis co-ordinates and bin widths.  So we'd like to
be able to export those via FITS, although I'll admit these features
aren't widely used in our community.  They could be added as extra
columns of a -TAB table at some point.

>   The suggested formulae for refractive indices in Chapter 4 are
>   inappropriate for IR wavelengths > 2microns, which are in
>   common use.

Given the growing importance of IR observations, can we find a tame IR
spectroscopist or instrument builder to write a subsection containing
the appropriate formulae and describe their applicability?

> I think the simpler forms of the -TAB table lookup capability will
> be popular.

Here-here!

Malcolm Currie