On Wed, 15 Jul 2009, Tim Jenness wrote:
> I am confused. Just because someone could not use FITS-WCS does not mean
> that paper III was a waste of time. This was a solved problem. With a
> LutMap you won't get any additional metadata to tell you how to convert
> to velocity and what rest frame is used without providing additional
> metadata and that may as well be the fits paper III headers such as
> RESTFRQ.
>
> > None of this touches the additional consideration that we need the
> > spectral WCS anyway to complete datasets like spectral cubes.
>
> Indeed. How is that going to happen?
I'll try to add a bit of light, rather than criticism to wind up this topic.
The IVOA spectral data model does define the additional elements required
to get back to FITS paper III. In the FITS serialisation this is part of
the table parameters, where there is a transliteration from STC to FITS
keywords, so now AST can handle STC-S I can probably get a fully specified
SpecFrame from such a table. For the XML serialisation it is presumed to
be in STC-X. These have been on the SPLAT todo list for a while (I don't
recall seeing spectra with this level of WCS support, so no urgency).
BTW, one thing I didn't point out yesterday is that another requirement
for spectral data is the construction of SEDs, that really stretches 1D
FITS.
For images there isn't a data model, so they are essentially FITS images,
but with the twist that they can be delivered in a package using the SIA
protocol which defines additional meta-data, like a primitive WCS in the
version 1.0 release. So the presumption there is that you can use the
wrapper WCS, or if you can handle it the FITS one.
I imagine a similar situation will used for cubes, since they extend SIA.
Plus of course now that STC is being more widely talked about that would
form part of the package to define the WCS, externally to FITS.
For TAP access I guess that is a bespoke access mechanism so you assert
that you can handle the things you ask for.
Just what I think the position is so your mileage may vary etc.
Peter.
|