WD-SIA-2.0-20140512 available

[Douglas Tody]

On Sun, 18 May 2014, Walter Landry wrote:

> Douglas Tody <dtody at nrao.edu> wrote:
>> 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.
>
> I must be missing something.  If an analysis program wants a mosaic
> image, then it asks for it.  It can not use the same query as SIA
> anyway because parameters will be different (e.g. options for
> background leveling).  The only advantage I can see to an SIA-type
> query is if you just wanted to check whether a mosaic image is
> possible (e.g. for a service that has patchy coverage).  Then you
> would not have to download the mosaic image.  But that can be handled
> with an option to AccessData with something like FORMAT=boolean.  That
> would also mean that the service might be able to skip the actual
> mosaic creation and return much, much faster.

You are thinking in terms of a complex mosaicing algorithm and mosaicing
task that the client might want to control explicitly (like Montage for
example).  This is a valid and important use case, however image
mosaicing is a special case of automated image generation to match
client-specified parameters, e.g., for spatial coverage and WCS.  If the
client just wants an image from some collection or waveband with the
specified coverge and WCS, this may in general require generating a
dynamic mosaic of multiple input images.  In the simplest case the
client lets the service use default values for all algorithmic
parameters.  They may want to broadcast this as a search query to
multiple services to see what is available, not knowing anything about
the services other than they can generated mosaic or matched images.

If they really want to generate a custom mosaic and control everything,
then they probably have to know a lot more about the specific service
and algorithm they are dealing with.  This is also an important use
case, similar to slicing and dicing a cube where the client specifies in
some detail exactly what they want back.  But both are important use
cases.  The first case (match my requested field) is often enough and a
whole lot simpler for the client.  Ideally we would like to support both
cases, with the ability to drill down and control the details if
necessary.

 	- Doug



>>> 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?
>
> This sounds good.
>
> Cheers,
> Walter Landry
>