Simple use case for SAMP ??

Tue Feb 17 15:34:34 CET 2015

Hi Petr,
Hi all,

Concerning Aladin, I'm not sure that I fully understand the SSA SAMP 
problem associated to the example that you sent to me (direct mail).

If I load this example in Aladin, it is correctly recognized as a SSA 
result (thanks to SSA utype signature), displayed in a dataset selector 
frame, and you are free to load a individual data set if you have a 
Spectra VO tool SAMPified running (Aladin is not designed to draw spectra).
In another hand, if you want to see the list of dataset displayed as a 
catalog, you have a dedicated popup menu for this task (see below).

The fact that Aladin does not display a SSA result as a classical 
VOTable catalog was a decision. Before TAP, SSA results were only 
generated by cone search resquests, meaning that all returned spectra 
were localized around the same target. So the choice to display this 
kind of results as a list of data sets, rather than a catalog was 
preferable (same behaviour that SIA results)
May be, we could imagine to invent a SAMP keyword for helping the client 
(here Aladin) to choose the best appropriate display mode. You can also 
remove specifical SSA utypes for forcing Aladin to load it as a 
classical catalog.

Independently to the SSA behaviour related above, until now, Aladin was 
not supporting the case where the coordinates were expressed as a tuple 
in an unique column. I'm not sure that the COOSYS VOTable mechanism (or 
STC note) has been foreseen this case, but clearly, Aladin did not. I 
just improved my code (Aladin Beta v8.136) for supporting this 
specifical case. The UCD "pos.eq" or "pos.eq;meta.main" on the field is 
required. The coordinates can be expressed as a unique string or as an 
array of 2 doubles (SSA usage !?). The COOSYS or other variants of 
coordinate frame specifications are supported. It is available on our 
official Aladin page.

Cheers,
Pierre

Le 17/02/2015 04:15, Petr Skoda a écrit :
>
> 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                                                       *
> *************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150217/1fe8c726/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bfdjfhce.png
Type: image/png
Size: 179110 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150217/1fe8c726/attachment-0001.png>