Hi David,
here's some of my notes from ADASS and what I think they could mean for
each application (or area).
SPLAT
=====
Clearly this needs to read and write tables, FITS and VO.
On the spectral analysis side it needs to do deblending, fit many lines at
once, do some kind of line identification and offer wavelength
calibration.
For stellar work (hot stars) it needs interactive B-spline fits for
background estimation, plus some enhanced comparisons, such as line
flipping and interactive shifting.
The plotting needs log axes (for energy).
On the VO front we need to look at hooking into SSA services when they
become available.
Functionally it would clearly be more useful if it could be made pure
Java. One idea would be to see what would be left if AST was dropped and a
new graphics system introduced (the idea is that this would be context
pluggable, maybe with enhanced AST functionality being offered as a
web-service). Clearly this would rule out using FITS (1D) images and all
spectra would be read from tables with no WCS/units information (all this
since we loose the FITS WCS headers parsing). There are probably worse
consequences I haven't thought of...
GAIA or SoG
===========
One of these needs to be hooked into the SIA services.
If we tried this with GAIA we'd have to use the C++ library for VOTable
access.
Colour image services could be targetted at SoG, which can display JPEGS.
I problem I can see with this being really useful is retaining astrometric
meta data. Don't know if this is kept (VOTable would be an obvious place,
but HDX would be better).
ds9 has broken though the 2Gb barrier.
Application web services
========================
This effects SPLAT, SoG and Treeview, I think we need to revisit
web-services in light what we saw in the VO tutorials. We could supply
WSDL generated Java classes as front end, if the end-point is
parameterised (at present we use a less elegant method).
BOY
===
Did he really say 112 CCDs in the QUEST survey!
Cheers,
Peter.
|