WD-SIA-2.0-20140512 available

[Douglas Tody]

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
>