Simple use case for SAMP ??
Petr Skoda
skoda at sunstel.asu.cas.cz
Tue Feb 17 04:15:14 CET 2015
Hi all
I wanted to demonstrate the students the power of VO technology on simple
use case which was IMHO straightforward, however it seems that even on
such a simple case all the VO implementation is uncovering its week
points rather than convincingly showing the synergy behind it .... Please
help!
We have spectra in SSA services. Every observed target should have somehow
encoded its coordinates in J2000 or ICRS. So the SSA query response
VOTABLE should contain the coordinates clearly identified by some UCD and
UTYPE (described in SSAP doc)
We have SAMP sending VOTABLES.
We have catalog tools like Aladin accepting SAMP sent VOTABLE and plotting
objects in it according to the coordinates.
Now I have simple task - I get somehow a bunch of spectra ( e.g. in
SPLAT-VO or through web samp connector from web service)
getting all SSA metadata in VOTABLE.
I want to send this table to Aladin to plot positions of all objects in
all-sky surveys like DSS. In fact it should be like sending a catalogue
and interpreting the coordinates in it.
Why this fails :
1) Not all SSA services have columns for RA and DEC separated - some are
only stating tupple of coordinates (e.g. MAGIC service has only SpatialLocation
column (262.077,50.126) etc ....
the SAMP sending in Interop menu is OK but understanding and interpretting
the acquired votable is not working mostly .... except of TOPCAT ...
The most critical part seems to be Aladin which does not understand the
coordinates in tupples or even string like e.g.
ssa_location = Position ICRS 304.444 45.2803
which is e.g. case in DaCHS served SAMP tables sent from web interface
In SSAP 1.1 is said that the Mandatory parameter is
(in 4.2.5.10 - page 37)
Char.SpatialAxis.Coverage.Location.Value which is expected (page 66)
to be tupple of double numbers (UCD pos.eq).
Most people are adding (for the above said reasons) the separate columns
(e.g. archive.stsci.edu) char.spatialaxis.coverage.ra (named ra_obs) and
char.spatialaxis.coverage.dec (dec_obs) with UCD pos.eq.ra;meta.main and
pos.eq.dec;meta.main respectively.
In addition there is another tupple named coord_targ with UCD pos.eq;src
which is basically the same as the mandatory pos.eq.
So what should be done for better interoperability ?
Should the Aladin understand the SSA mandatory tupples and interpret it ?
Or should even understand the string "Position ICRS xx yy" and use it for
catalogue entry ?
Should TOPCAT decode this string (or tupple) and use it as atribute for
plotting graphs ?
Can we send in SAMP such strings or tupples - including UCD it should be
self-describing ....
----------
BTW of course I can do the sending by SAMP to TOPCAT, activating the
function "Transmit coordinates", selecting the appropriate RA column and
Dec column, targetting the selected application - Aladin and then I may
click on rows to see the points in Aladin. But it is too much manual work
and (even if scripted) against the spirit of VO ideas.
IMHO the Aladin should somehow react to received SAMP table - e.g. shoul
d I treat the table as a catalogue - instead of simply creating list of
URLs as it does now.
The function - create the new plane with all images/spectra (activated on
right click of the URLs list does not remember all metadata received - it
tries to find the RA and DE though.
To summarize - we have all the components of the above shown use case but
they are NOT INTEROPERABLE !
Any suggestions ? recommendations ?
Best regards,
Petr Skoda
*************************************************************************
* Petr Skoda Phone : +420-323-649201, ext. 361 *
* Stellar Department +420-323-620361 *
* Astronomical Institute AS CR Fax : +420-323-620250 *
* 251 65 Ondrejov e-mail: skoda at sunstel.asu.cas.cz *
* Czech Republic *
*************************************************************************
More information about the apps-samp
mailing list