spectral WCS in FITS

[Andreas Wicenec]

Hi Anita,

I think we should start with the following concept:

- Convert FITS binary tables to VOTable with <STREAM> elements or binary 
attachments, i.e. don't touch the binary part, but just describe it.

- Convert FITS ASCII tables to fully tagged VOTables with <TABLEDATA> 
elements.

The reverse conversions should then also be possible (see my example).
The cross conversion between the two is more tricky and requires that the 
converter needs to know how to deal with the binary part. This is also 
possible, but not with plain XSLT although it can be done by using external 
functions called by the xslt processor. I did bot try it yet, but I guess it 
is not really complicated for simple binary tables. The problem starts when 
you want to deal with complicated radio or other interferometric data which 
are represented using hierarchical table structures with many multiplicity 
levels (baselines, basebands, polarisations, frequency channles). VOTable is 
not yet able to fully deal with this kind of data and the way it is 
implemented in FITS is also not really self-describing, i.e. there is a lot 
of implicit knowledge necessary to interpret the complete data structure of 
something like an AIPS++ measurement set. On the other hand the amount of 
data and the complexity of such structures makes pure ASCII representations 
pretty bulky and nobody really gains from being able to read it or load it 
into an editor, because it is almost impossible to do anything reasonable 
interactively anyway.

Another comment to your and Doug's e-mails yesterday:
We made quite some progress with the ALMA data model during our meeting in 
Santa Fe last week (Doug was present as well). There will be another round in 
January with less people to bring this to a level where we can actually draft 
a document on it. After this I think we should also open this up for 
discussion on radiovo at ivoa.net.

Cheers,
Andreas

On Thursday 27 November 2003 20:13, Anita Richards wrote:
> Yes but "The binary data is still kept as external links in a STREAM
> element"
>
> If that is what we are talking about then there is no problem... what I
> *thought* was the problem included the possibility of converting spectral
> data in the form of FITS tables entirely to VOTable (probably OK?) and
> back again.  But if no-one wants to do that, that is fine...
>
> a
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Dr. Anita M. S. Richards, AVO Astronomer
> MERLIN/VLBI National Facility, University of Manchester,
> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
>
> On Thu, 27 Nov 2003, Marco C. Leoni wrote:
> > Anita,
> >     about the conversions FITS<--->VOTable there was the proposal from
> > Andreas, please have a look at:
> > http://www.ivoa.net/forum/votable/0217.htm
> >
> >
> > Cheers,
> >     Marco
> >
> > Anita Richards wrote:
> > >On Thu, 27 Nov 2003, Markus Dolensky wrote:
> > >>>However
> > >>>unless I ahve misunderstood the debate, there is no question that the
> > >>> data _can_ be handled, it is simply a question of how,
> > >>
> > >>The question is whether we can perform the conversion between VOTable
> > >> and FITS format using off the shelve tools (XSLT). If not we need to
> > >> write Astronomy specific parsers which 'understand' the data whereas
> > >> we would prefer to apply just syntax rules instead.
> > >>
> > >>Markus
> > >
> > >For FITS to VOTable, there is also the tool being developed by VO India
> > >http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm
> > >which is indended to eventually cope with FITS.
> > >
> > >But what about the reverse? That is more difficult, surely?
> > >
> > >cheers
> > >a
> > >
> > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > >Dr. Anita M. S. Richards, AVO Astronomer
> > >MERLIN/VLBI National Facility, University of Manchester,
> > >Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> > >tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).