<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Tom, all<br>
Thanks for this email and thanks to Walter for the complement<br>
I only adress your first point today. Not that I am not interested
in Point 2? but it will come later.<br>
On 02/03/2016 23:01, Tom McGlynn (NASA/GSFC Code 660.1) wrote:<br>
</div>
<blockquote cite="mid:56D762BA.2010503@nasa.gov" type="cite">Now
that SIA V2 has been approved I've been contemplating how if and
how I might implement it for access to the SkyView services
managed at the HEASARC. I'm sharing some ideas with the DAL group
since I think some of these thoughts may have more general
relevance. <br>
<br>
I expect the ability to select SkyView surveys based upon
coverage, bandpass and resolution should be very helpful. However
there are two aspects that may be somewhat problematic. <br>
<br>
1. SkyView is a cutout and mosaicking service. So in terms of
retrieving an image SkyView needs two kinds of inputs: those that
select the survey or surveys we are interested in (e.g., bandpass
and resolution) and the WCS parameters that define the region to
be generated. Even in SIA v1 it was unclear how to convey this
information, but since the standard required a position/size input
it was pretty straightforward to implement a 'reasonable'
approach. SIA V2 is far more flexible. It not only doesn't
require a positional constraint at all, it allows users to define
regions that are a union of a variety of shapes. There seem to be
three options here for going forward: <br>
a. Use the inputs to the SIA V2 service purely for survey
selection and return no actual pointers to data. Instead return
datalink requests where the user will be prompted for the actual
bounds of the images desired for a survey which meets the
requirement. I.e., the positional inputs would be used only to
define a region in which the survey is to have some coverage, but
the user would later have to input the exact bounds for the subset
to be created. <br>
I'm not clear if datalink can be used this way: to get
additional data from the user. Even if it can, it seems clumsy
and makes the V2 interface take an extra step compared to v1. <br>
<br>
b. Use the positional constraint (all-sky if not specified) in
both the coverage request and the specification of the image to be
created. This is essentially what we do in v1, but we need to
understand what to do with multiple POS fields, and with POS
fields that aren't easily transformed to a rectangle on the sky.
We can treat each POS field as a separate request, or we can
contemplate the region defined by their union. <br>
<br>
c. Use either fixed values for the WCS parameters, or pass them
using non-standard parameters in the SIA call. We did some of
this in the SIA v1 version where users could override defaults
like the resampling method and map projection this way. However
if the user needs to specify critical features like the image
center and field of view of the image this way, then they are
often going to be duplicating information, and they won't be able
to use the SkyView SIA normally. <br>
<br>
<br>
Option b seems best, but it requires some more or less arbitrary
decisions. My initial thought is to treat each POS field
separately (perhaps with a non-standard parameter to request the
union). The field of view would be the smallest rectangle that
encloses the requested region. This isn't perfect but I think it
will meet most users needs. Since there are many cutout services
out there, some general guidance on how such services should
provide SIA2 access would be helpful. <br>
<br>
</blockquote>
<ul>
<li> The problem is that SIAV2 has been designed to fully take
into accounts all the axes of ND-CUBE (so much more than SIAV1
on that) but is poorer in functionality AS FAR AS
FUNCTIONALITIES are CONCERNED It is poorer. SIA1 distinguished
clearly four SERVICE TYPES:</li>
</ul>
Point archive, Atlas Archive, Cutout and Mosaic. <br>
(and more or less so did SSA which is indeed planned to allow some
cutout or mosaicking in the spec)<br>
As a first approximation we have two main groups : archived
(images, cubes) and virtual data (cutouts, or mosaics) <br>
<ul>
<li> SIAV2 in its SIAV2.0 sub-version is only an archival
type service. (and actually ObsTAP also describe only archive
data) . The "Server side Operations for Data Access", necessary
to generate virtual data is done by SODA. SODA1.0 only does
Cutouts. No Mosaicing for the moments ( This is actually
planned for version
SODA1.1)
So we are really building something like your option "a)"<br>
</li>
</ul>
The path from discovery to SODA (using DataLink, service
descriptors, in various subtilities) is currently hardly discussed
and it has been summarized yesterday by Pat. But anyway you have
SIAV2 and you "finish" with SODA. <br>
<ul>
<li> Your option b) ACCORDING TO SOME OF US (including me, but
I don't think there is a consensus on this) will be in the scope
of version SIAV2.1. (this was done in the "cutout" service type
case in SIAV1 but only for 2D images of course). In that case
you have an option and you discover virtual data an associated
soda service is able to provide you. The accessReference is now
no more a full retrieval of an archived image or a DataLink
pointer but a full SODA query URL driving the generation of the
cutout you want. <br>
</li>
<ul>
<li>That's a good rationale to keep the SIAV2 and SODA syntax
similar.</li>
<li>There some tricks in how an SIAV2 (or a virtual ObstAP)
service could communicate</li>
</ul>
<li>Your option c) assumes we allready have a SODA 1.1 able to
provide not only cutouts but also "mosaicking" that is
resampling , regridding, other kind of basic processing. As soon
as we have this we could imagine how we should extend SIAV2
syntax to force discovery of such transformed data. This is
probably for a version SIA2.2 but you can have custom parameter
in the mean time as soon as we have the virtual data option
available.</li>
</ul>
<p>Cheers<br>
François<br>
</p>
<pre class="moz-signature" cols="72">--
=====================================================================
François Bonnarel Observatoire Astronomique de Strasbourg
CDS (Centre de données UMR 7550 CNRS / Université de Strasbourg
astronomiques de Strasbourg) 11, rue de l'Université
F--67000 Strasbourg (France)
Tel: +33-(0)3 68 85 24 11 WWW: <a class="moz-txt-link-freetext" href="http://cdsweb.u-strasbg.fr/people/fb.html">http://cdsweb.u-strasbg.fr/people/fb.html</a>
Fax: +33-(0)3 68 85 24 25 E-mail: <a class="moz-txt-link-abbreviated" href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</a>
---------------------------------------------------------------------
</pre>
</body>
</html>