Reflections on SIA V2 and generic cutout services

[Markus Demleitner]

Hi Walter,

On Thu, Mar 03, 2016 at 12:39:24PM -0800, Walter Landry wrote:
> "Tom McGlynn (NASA/GSFC Code 660.1)" <tom.mcglynn at nasa.gov> wrote:
> > 1. SkyView is a cutout and mosaicking service.  So in terms of
> > retrieving an image SkyView needs two kinds of inputs: those that
> > select the survey or surveys we are interested in (e.g., bandpass and
> > resolution) and the WCS parameters that define the region to be
> > generated.
> 
> I had the same problem with our Planck image generation service.  SIA2
> is really not set up for this.  SIA2 is much better for retrieving
> links to existing images.  For example, your mosaicing service might
> have a multitude of options on how exactly to stitch images together.
> The best conceptual match I could find was something like SimDAL,
> which allows for this sort of extensive computation in order to
> generate an artifact for the end-user.  With that said, I have not
> actually implemented anything like SimDAL for our service.

These kinds of things are very much what I'm sure we have to cover in
SODA and why I'm so keen to keep it easily *and interoperably*
extensible.  And no, I'm totally against postponing "support" for
this to SODA 1.1.  Sure, we won't give the parameter prototypes
("three factors") for such parameters in 1.0.  But SODA 1.0 clients
should already support this by virtue of discovering parameter
metadata by dataset and building UIs based on that.

Can't you just try to formulate the paramters you need and see how
they come out in SODA?  And what's missing in case it's not
straightforward?

It'd be a great test to see if SODA clients actually do the right
thing, it'd be great as models for other services, and from the
collected experience we could then derive how to actually
standardise parameters for this kind of thing.

Cheers,

       Markus