SSA working draft

[Doug Tody]

Hi Inga -

On Tue, 21 Nov 2006, Inga Kamp wrote:
>> Actually this is a good question: should we define a preferred format
>> in which we would like to get spectra back?  This could be desirable
>> so that clients don't have to be prepared to deal with all the various
>> kinds of data formats (the main reason we define multiple formats
>> is so that the client can get whatever it prefers).  If we suggest
>> a format to support my tendency is to go with VOTable for spectra
>> since it is much better than FITS for metadata, and ok in terms of
>> efficiency in most cases for spectra, especially if protocol-level
>> compression such as gzip is used.
>>
>
> Most Astronomers would not know what to do with a VOTable. It might be a
> convenient format for all the metadata, but supposed that the person who
> is exploring the VO and discovering the data actually wants to use it,
> FITS is the more natural way to go. It works with all major astronomical
> software and data analysis packages. Moreover, there are now many
> FITS-readers out there, so that even non-Astronomers won't have any
> problems with it. We should keep in mind that our end-clients are still
> mostly humans and mostly astronomers.

I agree that the client software might prefer to get FITS back,
or CSV/TSV (simple text) for that matter.  However do not assume
that VOTable format will not be useful for real world analysis.
We are already working to interface this to the major astronomical
packages and tools.  I think we will need the big three (VOTable /
FITS bintable / simple text) for the indefinite future, and which is
best depends upon what you are doing and what software you are running.


> You have to see also the conflict with the data model. Both cases have
> this aperture "keyword/parameter". However, once it's the extraction
> aperture, once the instrument aperture. When we archive grism spectra, we
> want definitely to store both and be able to pass both on in the response!
> Even if the instrument aperture is not a query parameter, this causes
> problems in the data model.

After we do an extraction with a specified aperture, the aperture
value which comes back in the data model *is* the instrument aperture.
If spectral extraction occurs upstream (before the service runs) then
the aperture parameter is not used and all we have is the instrument
aperture.  I think the only real source for confusion is in the use
of the aperture parameter in the query interface; as you suggested
earlier, someone might guess that this is used as a query constraint
rather than for on-demand spectral extraction.

 	- Doug