On Wed, 5 Jan 2005, Mark Taylor wrote:
> On Wed, 22 Dec 2004, Peter W. Draper wrote:
> > Now for the wishlist that immediately occurs to me.
> >
> ...
> >
> > - support SIAP and SSAP queries. Clearly there's no reason why the
> > VOTables that these return cannot be displayed in TOPCAT. Of more
> > interest would be some intelligent connections to SPLAT and SoG
> > (duplicating some of what I've done for SPLAT, but so what).
>
> I've had a go at this for SIAP at least. If you do 'topcat -siap' (or
> if you like typing a lot 'topcat
> -Dstartable.load.dialogs=uk.ac.starlink.vo.SiapTableLoadDialog') and go
> to the load dialogue you'll see a "SIAP Query" button which gives you a
> dialogue much like the Cone Search one. Having filled in the form and
> loaded the result into TOPCAT, if you then go to the Activation Action
> window (button at the bottom of the Control Window right hand panel) and
> select the 'Display Named Image' option, you'll see it's initialised to
> the column which contains the SIAP ACREF URL. The upshot of this is
> that subsequently activating a row of the table, e.g. by clicking on it,
> will kick off SoG to retrieve and display the image in question.
>
> You'll need up to date versions of TOPCAT, TABLE, VO (and UTIL?) for this.
>
> I'm not sure though that TOPCAT is the best place for this functionality
> - users probably aren't going to think of the results of the SIAP query
> as a table, or want to look at them in a general purpose table
> manipulation tool such as TOPCAT. It sounds more like a job for windows
> hanging off SoG to me - and indeed this is what you've done with SPLAT
> and SSAP (possibly I've misinterpreted what you meant by your wishlist
> item above?)
Hi Mark,
that's almost what I had in mind, but like you I do think the division
between SSAP, Cone Search and SIAP is a little unnatural for TOPCAT, so
let me have another go...
Say if I wanted to look at all the data available for a region of interest
on the sky, I'd want to look at the images, spectra and tables pretty much
from the same application using the same query. So my initial thought was
really that an extension of the original query window to also return SSAP
and SIAP services (plus whatever else is to come) simultaneously would be
more natural (does rely on a unified query being possible, but I doubt
that the basic centre and radius will go away).
You could then select as many of these services as you want and perform
the query to get several catalogues, one per-service, or more
interestingly a single joined catalogue (although I can immediately see
that could be tricky as the "url" fields from services of the same type
would clearly clash).
Once I have all these queries I'd then naturally like to select some (and
create a join from them?) and push the images and spectra to suitable
tools.
> The main difference between what I've got and your SSAP/SPLAT loader is
> that you have a static list of SSAP servers for SPLAT rather than
> getting them from a registry. There are pros and cons to that - in many
> cases the user probably doesn't want to worry about what servers to use,
> and with only the three in existence using them all is reasonable, but
> as more arise that will be less tenable (there are currently 40 SIAP
> services advertised in the registry and 272 cone searches).
Agreed, I intend to switch to using your code for doing SSAP and SIAP
service queries (maybe retaining some idea of a list of what will now
become preferred services).
> I may knock up an SSAP loader too in any case, just because it should be
> pretty easy having done the SIAP one. Do you know where I can find
> whatever passes for an SSAP standard? The only thing I could find at
> IVOA was extremely sketchy.
That's right, last time I looked the SSAP documents were a mess and I've
mostly just followed the VOSpec lead. The poster from last summer suggests
things may get significantly more complex before the final standard comes
out, so just follow what SPLAT does for the moment (very SIAP-like).
Cheers,
Peter.
|