[cube access] minutes from telecon (2013-07-03)

[Douglas Tody]

Interesting discussion.  My view, having read through all the postings,
follows.

*** SUM, AVG, INTEG, moments, etc.

This is an important issue (especially for the more general AccessData
problem, not just the cutout prototype).

We have at least two cases here, purely mathematical functions that are
easy to define and are predictable, and algorithms.  The latter are
probably what is most often used in real use cases, however the
algorithm used will in general depend upon what software is used on the
back-end, while we are trying to design a uniform VO interface where the
client doesn't necessarily know what specific algorithm is used by the
service implementation.

I am thinking that we need to define some standard functions and allow
the service to match a smart algorithm up to whatever generic class of
function was requested, describing in the response what was actually
done.  This can probably work for standard functions like integrating
intensity or moments.  A specific service can extend this set to provide
nonstandard custom functions, or optional (nonstandard) control over the
algorithm to be used, which can be useful when the client software knows
about the specific service it is using.

For the simple "cutout" prototype this is too ambitious, it should be
left to the AccessData prototyping, which we need for our full up cube
access prototyping.  The most we might want to do is define more
precisely what is permitted for something like SUM, e.g., if the
channels are not equal in size, compute the integral instead.


*** STC-S and Cutouts, Coord frames

I thought we agreed in the telecon that the cutout prototype would only
do real cutouts - no resampling.  It is automatically generating a data
product hence precision is not required.  If the spatial region is not
aligned with the image axes one just returns an image cutout which
includes the specified spatial region (if it is a bit bigger that is
fine).  The projection in the returned image may be anything and will
generally not be aligned with the requested region.  The returned image
may have blank regions, but that is always the case.

More generally, the STC-S string (e.g. REGION) -- or an equivalent set
of range-valued parameters -- can be used for either discovery or
virtual data generation.  It is useful to support both ICRS and Galactic
for both use cases since the spatial region has extent (I see no need
for FK4, FK5 in input parameters).

For discovery it is all quite simple, we just find data that overlaps
the requested region.  For a cutout the returned data may only
approximately fit the requested region.  For something like AccessData
which can reproject the image, the exact region requested can be
returned (but may still have blank regions).  The initial cutout
prototype is a restricted subset of these use cases, but some of our
prototypes will be doing all these things.

Unless the service supports full reprojection, the permitted *input*
frames for the spatial region can be limited to ICRS, Galactic.  For
*output*, in general the WCS of the output image may be anything, and is
whatever was used in the original archive data - in most cases, it is
probably an instance of a FITS WCS.

 	- Doug