Reflections on SIA V2 and generic cutout services

[François Bonnarel]

Hi Tom, all
     Thanks for this email and thanks to Walter for the complement
I only adress your first point today. Not that I am not interested in 
Point 2? but it will come later.
On 02/03/2016 23:01, Tom McGlynn (NASA/GSFC Code 660.1) wrote:
> 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.
>
> 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.
>
> 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:
>   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.
>   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.
>
>  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.
>
>  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.
>
>
> 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.
>
  * 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:

     Point archive, Atlas Archive, Cutout and Mosaic.
  (and more or less so did SSA which is indeed planned to allow some 
cutout or mosaicking in the spec)
      As a first approximation  we have two main groups : archived 
(images, cubes) and virtual data (cutouts, or mosaics)

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

     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.

  *     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.
      o That's a good rationale to keep the SIAV2 and SODA syntax similar.
      o There some tricks in how an SIAV2 (or a virtual ObstAP) service
        could communicate
  * 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.

Cheers
François

-- 
=====================================================================
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:http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 68 85 24 25     E-mail:francois.bonnarel at astro.unistra.fr
---------------------------------------------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160304/c6c6880c/attachment.html>