Multi-dimensional Data Access minimal requirements

[Douglas Tody]

On Tue, 11 Mar 2014, Douglas Tody wrote:

> 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

Well, half as big, but you get the point.

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