Simple use case for SAMP ??

[François Bonnarel]

Hi Petr,
    I don't think it's specifically a use case for SAMP but a use case 
for interoperability.
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 ....
Yes the only standard  for SSA is the 2007 recommendation (SSA 1.03) 
revised in 2012 (SSA 1.1). And this specifies the SpatialLocation as a 
single field containing a tuple instead of two fields.
Old Prototypes of SSA, very similar to SIA 1.0 specifies the sepctrum 
position via two fields

By the way SSA is the only standard specifying a dataset position using 
one single field. SIA1 did not , SIA2 will not and OBscore / Obstap 
doesn't either. There has been a discussion when Obscore (which is 
posterior to SSA) was settled. Most of the people thought that despite 
the SSA solution, having two different fields was actually a better idea.
>
> 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
This is a bug in Aladin which should interpret the tuple correctly. 
Aladin loads rather seldom spectra I guess. The only use case is to see 
the position or aperture on top of an image. If the Optional 
SpatialAxis.coverage.support.Area is provided Aladin takes it into 
account and is able to display the contour (assumed to be written  using 
STC-S)
> 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
This is however not Standard. STC-S according to OBscOre for example is 
only used in the support (SpatialAxis.coverage.support.Area, i.e the 
apperture or FOV of the spectrum.
>
> 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).
>
Yes
> 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 ?
Yes
>
> Or should even understand the string "Position ICRS xx yy"  and use it 
> for catalogue entry ?
I would say : no, at least if it is to be interpreted as the location. 
The coordinate system is given elsewhere in the table. And discussion in 
Hawai showed that people  were reluctant to keep STC-S content in the 
DAL query responses
>
> 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 ....
The problem is not SAMP but interoperability between clients like Aladin 
and servers like Dachs or whatever
>
>
> ----------
> 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.
I don't understand this point. It should  not work like this . Can you 
send me you table ?
>
> 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 !
>
Yes

Best regards
François
>
> 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                                                       *
> *************************************************************************