Reflections on SIA V2 and generic cutout services

[Patrick Dowler]

On 9 March 2016 at 08:30, François Bonnarel
<francois.bonnarel at astro.unistra.fr> wrote:
>Le 07/03/2016 16:16, Tom McGlynn (NASA/GSFC Code 660.1) a écrit :
>> Do I get back a rectangle that encloses that circle? How is such a rectangle defined?  What coordinates, projection?

>Yes, it was always the intention. If it is not obvious we have to clarify this in the text.
>>
>>   The last bit is probably less a problem for most cutout services since they'd do rectangles
>> in the frame of the observations.  But for SkyView where the whole idea is that the user gets pick these
>> things, it's quite relevant.
>
>Adding some recomputing facilities modifying grids and pixel values has been postponed to next
> version of SODA.

I would like to like to add to this as there seems to be a lot of
misconception about restricting the scope
and what that means; it is easy to read too much into what is in the WD.

Yes, future SODA revisions will add more functionality for access, as
was planned since the Hawaii interop and people can go back and look
at the DAL roadmap from that time and later. Since we are designing
something that has to evolve, the authors can draw a line and say that
specifying *that* is out of scope.. but what is in scope is to
discusss whether the things that are in there make future things
harder than necessary and/or impossible (meaning that thy would
require a major version number increase).

Currently, the SODA params just express a region-of-interest and in
that respect they mimic SIAv2 params because those also express an
ROI. The meaning of what happens in SIA-query vs SODA (search vs
cutout) is conveyed in the standardID and, if coming to SODA via a
DataLInk response, in the semantic tag.

With respect to our implementation (it is production code with access
to all our data; it is a prototype only in the sense that I'll change
the code to comply with whatever SODA spec we come to): the current
suite of DAL specifications (ObsCore-1.0 and/or Wd-ObsCore-1.1,
WD-DALI-1.1, TAP, SIAv2, DataLink, and WD-SODA-1.0) do fit together
very well and deliver the functionality required for the baseline CSP
use cases. There is room for improvement in WD-SODA, which I have
tried to demonstrate by including custom params that I think are
superior in the way one can legitimately convey useful metadata -- but
this *is not* a new feature or extension of the scope, just (in my
opinion) a better solution to the current minimal requriements.

There is some descriptive text needed somewhere to advise people
can/should (not must) convey parameter, but I'm not sure where that
should be written... probably in DataLink but it could feasibly go in
DALI if it can be written without circular reference to DataLInk
service descriptors (and then made more explicit in DataLink when we
get to a new minor version).

-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada