Multi-dimensional Data Access minimal requirements

[Robert J. Hanisch]

I would just add my vote that a circle specification for a cutout is not
the way to go.  Simple RA and Dec limits are much preferable.  Suppose I
want a rather long rectangle, covering a wide range of RA and something
quite narrow in Dec.  Limited to a circular cutout specification I will
get a much bigger cutout than I want, and this basically defeats the
purpose of getting a _cutout_.

I would not allow for four arbitrary corners of a quadrilateral, just
RA_min/max, Dec_min/max.

Bob

On 3/7/14 7:26 PM, "Douglas Tody" <dtody at nrao.edu> wrote:

>On Fri, 7 Mar 2014, Patrick Dowler wrote:
>
>> "circle' is not a typo. The user would specify a circular region of
>>interest 
>> and the service would return a rectangular array that includes that
>>circle. 
>> The use of a circle avoids anyone assuming that any rotation would be
>> applied. If the client specifies range of coordinates or a polygon, we
>>would 
>> have to be more clear in documentation exactly how those were supposed
>>to be 
>> treated as they do carry orientation information. Basically, circle has
>>no 
>> orientation so it never implies anything and is the simplest
>> region-of-interest to deal with.
>
>The basic concept of a cutout is that we "cutout" (without recomputing)
>a region in multi-dim space, defined by the range of coordinates in each
>dimension.  For the spatial limits of an image cutout the generalized
>cutout region is a rectangle; restricting this to a square box enclosing
>a circular region is unnecessarily restrictive without simplifying
>anything.  If we want to forbid rotation that is easily done by
>specifying the bounds of the cutout region on the two spatial axes.  The
>fundamental restriction is that pixels/voxels are not recomputed but are
>merely "cut out".
>
>> For cutouts, the parameters I have are essentially the same as the
>>WD-SIA-2.0 
>> basic query parameters (POS, BAND, TIME, POL): they specify a region of
>> interest. The difference is that one capability (and REQUEST value)
>>specifies 
>> searching for data and the other cutout from a single selected dataset.
>
>Good; the simple solution for both a discovery query and accessData is
>to have the same ROI/FILTER parameters be the same in both cases (POS,
>[SIZE explicit or folded into POS], BAND, TIME, POL).  The only thing
>missing is then the capability to automatically "discover" virtual
>images (cutouts or mosaics) in the discovery query.  This is quite
>important for example, when querying against a wide field survey where
>we have full coverage, and don't care at all about the individual images
>composing the survey region.
>
> 	- Doug