WD-SIA-2.0-20140512 available

[Tom McGlynn]

SkyView is a mosaicking service which is available through SIA and illustrates some of the issues 
that you have been talking about....

E.g., as Walter suggested, the actual SIA request does not generate images, it goes far enough to 
ensure that there is likely to be an image or images in the region requested and then simply returns 
the URLs that would generate them should the user decide they want them.  However presence/absence 
of the image isn't the only filtering the SIA service does.  In our case since we have surveys of 
vastly different resolutions, we also do a step where we compare the size of the requested image 
with the resolution of the survey.  So, e.g., if the user is asking for a 1' region, we won't return 
the IRAS or IRIS images that might be available in that region, since they have 1.5' resolution. 
Similarly we may not return very high resolution data or data with very limited coverage when the 
user is requesting an all-sky image.

There are lots of SkyView SIA services which generate multiple images: There is an overall SkyView 
SIA service which will typically return dozens of images in different wavebands, but a more common 
use case is likely to be something like the WISE or the SDSS where there are multiple wavebands that 
are associated.  The user can choose which of these to get.  While it would certainly be possible to 
have a separate SIA service for each waveband, it doesn't seem particularly better.  In the near 
future as we start to get services like LSST on-line, I could envisage an SIA service that does 
mosaicking of images taken on a single day (or small range of days), but provides separate mosaics 
for data taken at significantly different epochs.

There are lots of parameters available to control the image generation within SkyView.  The URLs 
returned by a barebones SIA request use our default set, but the SIA service can be augmented by 
other parameters if the user wants.  So a discovery query can find the data the user wants without 
being burdened, by special parameters.  Once a user knows that a particular data set is of interest 
they can decide if they wish to invest time in optimizing their access to it.


	Tom McGlynn

P.S.,  Personally I like to use the spelling 'mosaicking' since to my ear 'mosaicing' ends in the 
same sounds (though different accent) as 'icing' with a soft C.  However the barbarians seem to have 
stormed this gate and since about 1990 my preferred form is in the minority though it had previously 
been predominant.

Douglas Tody wrote:
> 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
>>