Simple use case for SAMP ??

[Petr Skoda]

> 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).

OK - so I'll repeat for all:

In the example votable (which is response of MAGIC service - BTW the best 
example of simplest SSAP using only mandatory parameters) there is only

<FIELD ID="location_arr" arraysize="2" datatype="float" 
name="location_arr"
ucd="pos.eq" utype="ssa:Char.SpatialAxis.Coverage.Location.Value"/>

so IMHO Aladin should understand this ...

Some providers  are adding separate columns like pos_ra, pos_dec or 
ra_obs,dec_obs as well 
but it is not obligatory and in fact redundant.


> 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).

well I do not see below anything about it but I think you mean the 
right-click function as I have already mentioned (create new plane from 
all spectra) - it is not what I want.
It does not preserve other metadata like catalogue (on click on the 
created mark it shows only RA DEC)




Before TAP, SSA results were only generated by cone 
> search resquests, meaning that all returned spectra were localized around the 
> same target.

It is however importnat to see even spread of pointings in small circle - 
e.g. in clusters or on double stars..

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)

in fact on SIA it is also important to see the centers of images as well 
as coverage - in simple cases

> May be, we could imagine to invent a SAMP keyword for helping the client 
> (here Aladin) to choose the best appropriate display mode.

It would be nice - that's the reason why I present this in SAMP list as 
well - but as I am thinking about it - it seems more appropriate to add to
the SAMP configuration in Interop menu (SAMP preferences) the option
"View SSA as Catalogue" or similar ..

But how to tell it on local load of the votable ?

You can also 
> remove specifical SSA utypes for forcing Aladin to load it as a classical 
> catalog.

What utypes (what does the Aladin use as a discriminator)?
However I do not see this hack feasible when using SAMP (perhaps for 
manual modification) fo local load.
>
> 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.

OK - just the unique is the UTYPE as I see in some SSA services the same 
UCD pos.eq assigned multiple times on other coordinates expressions

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.

Thanks for the correction.

Anyway - what is the opinion of others? Is the client modification 
(interpreting table as catalogue) the good solution or should we enforce
some SAMP type telling if it has a coordinates it is catalogue and shoul 
d be displayed as such ?

In fact it seems to me that sending list of spectra to SPLAT should load 
their metadata and allow their downloading/plotting.
Sending the same to Aladin (which is known to work on catalogues not 
spectra) should treat it as a catalogue.

I do not see sense to send spectra list to Aladin and redirect it to SPLAt 
for display (or download) as it is now.

IMHO Every VO application has its own capability and so should response to 
SAMP sent table in the default way (which may however be changed if 
multiple interpretations are available)


The same with TOPCAT

Loading the MAGIC example in it -  it does not allow to interpret tupples 
so 
it gives me no chance to select and plot coordinates in its plotting 
window  -

I still feel it should as the coordinate tupple is official VO "datatype"


Best regards,

Petr

*************************************************************************
*  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                                                       *
*************************************************************************