Reflections on SIA V2 and generic cutout services

[Markus Demleitner]

Hi Tom,

On Mon, Mar 07, 2016 at 10:16:43AM -0500, Tom McGlynn (NASA/GSFC Code 660.1) wrote:
> While Walter may have a different response, my view is that while SODA gets
> us started on defining how we do subsetting, there's no obvious way to tie
> it to SIA to provide the kind of complete capability that the current
> SkyView SIA services (and other SIA cutout services) do.  So right now the
> latest version of our primary image access protocol cannot naturally access
> many of our image resources.
> 
>   - SODA looks only at the subsetting aspects of the query.  While it might
> be possible use SIA to expose SODA resources this brings us back to
> requiring a two step process where users enter data twice first to discover
> resources and then to subset them. This seems pretty clumsy.

Well, I'm pretty sure there's no good way around this two-step
process in the general setting -- the region of interest usually
simply is not enough to uniquely determine what a client wants to
retrieve.  It barely is in the 2D image case.

One good example is the dreadful FORMAT parameters in SSA and
friends.  Just to remind you: SSA and SIAP currently allow a client
to say FORMAT=compliant or similar if it only wants, say, SDM
compliant spectra, or FORMAT=image/jpeg if they're after
quick-download highly compressed images, etc.  This has the
side effect that absent FORMAT a service will return potentially
quite a few rows for each dataset, which is ugly in so many ways.
This becomes worse when you, for instance, offer various compression
ratios, files in different resolutions, etc.

And the problem immediately goes away with the second step that
deals with the actual retrieval modalities.

Note that most of this can be almost transparent to the user.  See
how Aladin currently does this: After the discovery query, you have a
set of matches, and when you click on a match, you get a dialog that
right now just displays some metadata and a get/cancel button.  It'd
be easy to have a couple of extra entry widgets (plus datalinks).  If
the client pre-fills the appropriate boxes (easy with three-factor
semantics), I don't think it's clumsy at all; and sensible defaults
also let you do the current double click.

>   - The names for parameters in SODA duplicate the names of the parameters
> in the SIA call.  Thus we're likely to get some confusion between parameters
> used for data discovery versus parameters used for subsetting.

Yes.  I also think that's an unfortunate design decision, in
particular as regards BAND.  And POS... Well.  However, I'd be very
reluctant to re-open this discussion now; as far as I can see, apart
from the potential for confusion, I don't see this as an actual
technical problem.

>   - The spatial subsetting is not well defined.  E.g., if I'm asking for a
> spatial subset where I've given  POS=CIRCLE 12 34 0.5 what do I get back?

Well, services are supposed to take the bounding box within their
native coordinates.  But sure, for this and many other reasons
(they're on my list of gripes), SODA really needs to support RA and
DEC, plus, once we can properly declare STC metadata in VOTables
again, limits in the native coordinate system.

RA and DEC, anyway, IMHO are indispensible when there's spatial data
involved, if only for an immediate (if rough) indication of the
dataset's spatial footprint.

> Do I get back a list of pixels that are within (or partially within) that
> circle?  Do I get back a rectangle that encloses that circle? How is such a
> rectangle defined?  What coordinates, projection?  The last bit is probably

Phewy, and I thought I was the only one finding POS... in need of a
lot of words.

> What I could see working is defining a service that is simultaneously a SODA
> and SIA service.  That would imply that the SODA parameters should have
> distinct names from the SIA names. Specifically for image cutouts there
> should be some way that the SODA POS could be inferred from the SIA POS
> fields.  The actual meaning of the cutout for a given POS field would also

No, *that* I don't like.  In case of a true mosaicing service, I
could see a pure datalink/SODA service, but even then I'd advocate
having a SIA service in front that always just returns one (or
however many mosaics you have) datalink -- for the simple reason that
we don't want to multiply the discovery options.  It's bad enough
that we have ObsTAP and SIAv2 (and SSA) in parallel. We should avoid
to force clients to look for SODA services on top.

Cheers,

          Markus