Multi-dimensional Data Access minimal requirements

[Robert J. Hanisch]

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

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