Multi-dimensional Data Access minimal requirements

[Robert J. Hanisch]

Specifying the region via RA and Dec range limits is not asking for any
dynamic computation, at least not in this iteration.  But "circle" is not
only counterintuitive for an image search, it is -- as I said before --
horribly inefficient if the region of interest is not close to square.

Remember, too, we are talking about the query that gets sent from the
interface to a service.  SIAP queries will most likely result from web
forms or programmatic interfaces in which user-friendly inputs can be
specified.  So we need not make the range specification so dumbed-down as
"circle".

Bob

On 3/10/14 6:07 PM, "Patrick Dowler" <patrick.dowler at nrc-cnrc.gc.ca> wrote:

>
>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)