Multi-dimensional Data Access minimal requirements

[Patrick Dowler]

It would not be hard, it would not be possible except with luck :-)

In the simple cutouts you don't get back a box/rectangle the size you 
specify unless the data happens to be aligned a certain way. None of the 
simple cutouts imply any kind of rotation or production of data that 
fits the rectangle specified. They are *all* just an expression of the 
region-of-interest and not an oriented data array.

Any kind of transformation is out of scope for 1.0 and will be the 
subject of future versions of the spec.

Pat

On 10/03/14 02:31 PM, Andreas Wicenec wrote:
> Hi all,
>
> this is pretty awkward, since it would be quite hard to get a square or a rectangle of a specific angular width back. I would propose the way good old astrores did it: specify center coordinates and a box size in degrees. If one value is given, the resulting image would be square, if two are specified it would be rectangular, always aligned to the centre latitude.
>
> Cheers,
> Andreas
>
> On 11 Mar 2014 08:04, "Robert J. Hanisch" <hanisch at stsci.edu> 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)