WD-SIA-2.0-20140512 available

[François Bonnarel]

Hi Walter, Doug,
     It's nice to see Mosaic services as a requirement from service 
implementers. I had no doubt about that anyway. Could imagine also cube 
mosaicking I guess.
    It's a strong driver to push an AccessData1.1 and SIAV2.1 as soon as 
we have the basic functionnalities (discovery and cutout) needed for 
cubes (AD1.0 and SIA2.0) as recommendations.
  Best regards
François

Le 16/05/2014 00:09, Douglas Tody a écrit :
> On Wed, 14 May 2014, Walter Landry wrote:
>
>> Douglas Tody <dtody at nrao.edu> wrote:
>>> Support for simple image mosaic (and cutout) capabilities is an
>>> important capability that is not currently adequately addressed.  As
>>> you say this capability has been in V1 for over ten years now.  In
>>> principle an SIAV2 interface could describe a virtual image such as
>>> a cutout or mosaic, however there is no support for this in the
>>> current specification, and the critical spatial query portion only
>>> provides a simple discovery capability for static archival images
>>> (the concept of the "ideal image" has been dropped).
>>>
>>> If people want these capabilities - speak up.  We already do all these
>>> things in prototype interfaces, but there has not been sufficient
>>> agreement to include such capabilities in the V2 specification.
>>
>> As someone who is currently implementing a mosaic service, I do not
>> think that the SIA model fits well.  Perhaps I have a lack of
>> imagination, but I would think that a mosaic service will either
>> succeed or fail.  It will not give several results that you then can
>> choose which to download.
>
> The point of the SIA query for virtual data such as a mosaic, is to
> automate the process (the client does not have to know much about a
> particular service or data collection), and allow the same generic query
> to be broadcast to any number of services without change.
>
> So for example an analysis program that wants images optimized for a
> particular field might broadcast the same query to multiple services
> with a mosaic capability, and merge the results into a list.  An
> individual service might return only a single candidate image.  The
> query response metadata describes the virtual image and can be used by
> the client or user to decide what data to compute and retrieve.
>
>> In that case, mosaic services are much more aligned with AccessData.
>> Mosaic services give the illusion of multi-dimensional dataset by
>> computing transforms on the fly.  My main complaint about AccessData
>> is that it is woefully incomplete.
>
> Actually computing a virtual image will fall to AccessData whether it is
> called indirectly via a SIA query, or directly by the client to
> explicitly compute a virtual image data product.  If the client request
> is wrong, AccessData merely returns an error (if an SIA discovery query
> comes first this won't happen as the service already composed a valid
> AccessData request).
>
> So at the level of AccessData, what is required to define a mosaic
> image?  Probably inputs (image collection to be used, or an explicit
> list of images), and parameters required to define the output (e.g.,
> image geometry and WCS of the computed output image).
> Algorithm-specific parameters might also be useful but require knowledge
> of the specific service hence would be optional custom parameters.
>
> In many cases a mosaic computation ought to happen fairly quickly (a few
> seconds or tens of seconds), however in some cases it could require
> async execution.
>
> Does this sound about right?  What are we missing for this use case?
>
>     - Doug
>
>> Cheers,
>> Walter Landry
>>