Multi-dimensional Data Access minimal requirements

[Douglas Tody]

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.

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