spectral WCS in FITS

[Doug Tody]

Hi All -

Bob writes:
> My concern is that the paper provides no simple FITS ASCII table
> representation for spectra in which the wavelength scale is given by an
> explicit list of values, each with an associated flux.  Rather, it supports
> a wavelength scale look-up using a FITS BINTABLE extension, and only allows
> the wavelength and flux arrays to be stored as vectors in single cells.

I have only just started to look at this issue, and may have better
informed opinions later , but I have a few initial comments.

First, BINTABLE is is a major part of FITS, used for much current
astronomical data.  We should not be trying to force FITS to abandon
BINTABLE for an inferior solution just because BINTABLE is inconvenient
to use with XSLT.

Having just read the latest draft WCS paper III it is clear that there
are good reasons for the use of BINTABLE for the sampled spectral WCS
coordinate vector.  The main reason for this is to allow a spectral
WCS to map cleanly onto a spectral data format which stores multiple
spectra as the rows of a binary table (a widely used technique which is
probably the best approach available for multi-object spectrographs).
This allows the use of a sampled WCS without having to use a separate
FITS extension.  If an ASCII table were the only option, it would be
necessary to use a separate ASCII table extension for every spectrum in a
multi-spectrum BINTABLE that might contain thousands of spectra.  Hence,
it is necessary for FITS spectral WCS to support BINTABLE for storing a
sampled WCS coordinate vector.  It is necessary to store the vector in
a single table cell to allow a direct mapping onto a spectrum stored as
a table row.  If only a single format option is provided, this would be
the best one to pick.

If we were to store a single spectrum in a single ASCII (or binary)
table, storing the vectors in columns of the table, then it would be
straightforward to have a column (rather than cell) for the sampled
WCS coordinate vector.  I see no reason this could not be allowed by
spectral WCS for single-spectrum-per-table spectral formats.  The cost
would be to provide two alternate options for representing a sampled
WCS coordinate vector.  The storage representation would differ from the
current spectral WCS spec, but the WCS data model is the same in both cases
(with the minor restriction that the index vector would not be permitted
for a same-table mapping, but it is not needed anyway for this format).

On the other hand we could also easily support the use of BINTABLE for
FITS spectra which map to VOTable.  If a table has only one row, there is
no significant difference between a vector valued table cell with N values
and a column with N rows.  Logically there is essentially no difference.
Since BINTABLE is already a binary format it really does not matter.
If we wanted to do text-based translation we could post-process the
text with a BINTABLE formatter component without loss of flexibility.
The real question is do we want to define multiple FITS spectral data
representations, e.g., for both ASCII tables and BINTABLE.

More on this later as we think more about spectral data formats for SSA.

	- Doug