<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
<div class="moz-cite-prefix"><br>
Hi Petr,<br>
Hi all,<br>
<br>
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).<br>
<br>
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).<br>
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).<br>
<br>
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)<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Pierre<br>
<br>
<br>
<br>
<img src="cid:part1.03000605.08020108@astro.unistra.fr" alt=""><br>
<br>
</div>
<br>
<br>
<br>
Le 17/02/2015 04:15, Petr Skoda a écrit :<br>
</div>
<blockquote
cite="mid:alpine.DEB.2.00.1502170204120.20807@pollux.stel"
type="cite">
<br>
Hi all
<br>
<br>
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!
<br>
<br>
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)
<br>
<br>
We have SAMP sending VOTABLES.
<br>
<br>
We have catalog tools like Aladin accepting SAMP sent VOTABLE and
plotting objects in it according to the coordinates.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
Why this fails :
<br>
<br>
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 ....
<br>
<br>
the SAMP sending in Interop menu is OK but understanding and
interpretting the acquired votable is not working mostly ....
except of TOPCAT ...
<br>
<br>
The most critical part seems to be Aladin which does not
understand the coordinates in tupples or even string like e.g.
<br>
ssa_location = Position ICRS 304.444 45.2803 which is e.g. case in
DaCHS served SAMP tables sent from web interface
<br>
<br>
In SSAP 1.1 is said that the Mandatory parameter is
<br>
(in 4.2.5.10 - page 37)
<br>
<br>
Char.SpatialAxis.Coverage.Location.Value which is expected (page
66)
<br>
to be tupple of double numbers (UCD pos.eq).
<br>
<br>
Most people are adding (for the above said reasons) the separate
columns
<br>
(e.g. archive.stsci.edu) char.spatialaxis.coverage.ra (named
ra_obs) and
<br>
char.spatialaxis.coverage.dec (dec_obs) with UCD
pos.eq.ra;meta.main and pos.eq.dec;meta.main respectively.
<br>
<br>
In addition there is another tupple named coord_targ with UCD
pos.eq;src which is basically the same as the mandatory pos.eq.
<br>
<br>
So what should be done for better interoperability ?
<br>
<br>
Should the Aladin understand the SSA mandatory tupples and
interpret it ?
<br>
Or should even understand the string "Position ICRS xx yy" and
use it for catalogue entry ?
<br>
<br>
Should TOPCAT decode this string (or tupple) and use it as
atribute for plotting graphs ?
<br>
<br>
Can we send in SAMP such strings or tupples - including UCD it
should be self-describing ....
<br>
<br>
<br>
----------
<br>
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.
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
To summarize - we have all the components of the above shown use
case but they are NOT INTEROPERABLE !
<br>
<br>
<br>
Any suggestions ? recommendations ?
<br>
<br>
Best regards,
<br>
<br>
Petr Skoda
<br>
<br>
*************************************************************************
<br>
* Petr Skoda Phone : +420-323-649201,
ext. 361 *
<br>
* Stellar Department
+420-323-620361 *
<br>
* Astronomical Institute AS CR Fax :
+420-323-620250 *
<br>
* 251 65 Ondrejov e-mail:
<a class="moz-txt-link-abbreviated" href="mailto:skoda@sunstel.asu.cas.cz">skoda@sunstel.asu.cas.cz</a> *
<br>
* Czech
Republic *
<br>
*************************************************************************
<br>
</blockquote>
<br>
</body>
</html>