Multi-dimensional Data Access minimal requirements

[Markus Demleitner]

Dear DAL,

On Mon, Mar 10, 2014 at 02:48:38PM -0700, Patrick Dowler wrote:
> 
> This functionality is supported in the WD-AccessData-1.0, specified
> using the POS=RANGE ...  construct the same way a query like that
> would be done in WD-SIA-2.0.
> 
> Both the circle and the range have their benefits. For people
> studying astronomical objects the circle is generally the most
> useful. For people examining a swath of sky (say as defined by a
> survey) the range is likely the more useful construct. The polygon is
> for cases when the other two are not precise enough (say a long
> narrow diagonal shape)... probably rare. But as I said, both will be
> available.

Wouldn't a simple specification consisting of RA, DEC, RA_WIDTH,
DEC_WIDTH be enough to cover both cases?  It would also nicely map to
all other float-valued axes (LAMBDA, TIME, X, Y, Z, REDSHIFT...),
yielding a uniform view of the cutout process.

Plus, using the PARAM declaration we know from SSAP and SIAP metadata
lets us specify actual ranges, roles in data models to be defined
later, as well as any other ancillary metadata we might not yet
realize we need.

And let me maintain again that in the cube cutout case communicating
values likely to give a result is even more important than with
discovery services, as the ranges of these values are typically
fairly small.  A previous discovery step *may* have given clues on
the ranges of these axes, but we should not rely on this -- redshift
isn't included in obscore, for instance, nor are cartesian
coordinates we may have in cubes from simulations.  Maybe there
hasn't even been a previous discovery step.  Hence: whatever
parameters we eventually go for, please keep in mind we need a
mechanism to communicate the ranges.

Incidentally, in my December proposal for data access services (in my
feedback to the datalink WD), I had suggested *_MIN and *_MAX as the
standard pattern for "structured parameters", mainly to keep "PQL"'s
range semantics and just clean up the syntax.  I'd like to retract
that now and suggest a center/size pattern (VAL/VAL_WIDTH) is almost
always more desirable because it's just as expressive but more robust
(e.g., in spherical coordinate systems near poles or stitching
lines).  I'll send around a proposal for this as soon as I've updated
my Datalink implementation to the new WD as well as this pattern.

Cheers,

       Markus