WD-SIA-2.0-20140512 available

[Walter Landry]

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.

>> 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