Multi-dimensional Data Access minimal requirements

[Douglas Tody]

On Tue, 11 Mar 2014, Robert J. Hanisch wrote:

> On 3/11/14 3:49 PM, "Douglas Tody" <dtody at nrao.edu> wrote:
>
>> A region specified as a RANGE of RA,DEC is not how to specify the image
>> footprint required for an image cutout, due to the cos(dec) term, and
>> due the fact that in most 2D projections of the celestial sphere lines
>> of constant RA,DEC are curved.
>
> I think in most use cases it won't make much difference.

The curvature issue may not matter much for a smaller image, but an
image specified with the same RANGE for RA will be twice as big at
+60deg as on the equator.  A 1-degree angular extent measured at the
reference point however (image center for a ROI), will be the same size
image in both locations.

> But either way,
> I still think "circle" is not what one wants for a cutout.  It's ok for
> discovery, but not for a cutout.

Exactly.  Circle is usable for discovery but not very useful to specify
the ROI for a cutout.  Note that in the discovery use case, there are
also issues with the size and coverage of the target image - is the
center of the target image in the specified circular region, or only
part of the image, is it fully contained, etc. (this was the point of
the INTERSECT parameter).

 	- Doug


>>
>> Instead we want to specify the image center and angular size in one or
>> two dimensions (as Andreas also said earlier).  In other words, POS
>> (image center), and SIZE (angular extent of the image in degrees).  Or
>> the same thing expressed as a more complex POS object supporting BOX or
>> RECT if you prefer.
>>
>> POS,SIZE is the 2D equivalent of a circle specified as a central
>> coordinate and diameter.  It is the natual way to specify an image ROI
>> as for an astronomical image, the central coordinate almost always has
>> some meaning (object position or field center), and wants to be
>> specified independently of angular extent or size.
>>
>> 	- Doug
>>
>>
>>
>>
>> On Mon, 10 Mar 2014, 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.
>>>
>>> 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)
>>>
>
>