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 dal mailing list