Multi-dimensional Data Access minimal requirements

[Patrick Dowler]

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.

Pat



On 10/03/14 02:04 PM, Robert J. Hanisch wrote:
> 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
>
> .
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)