Boxes and Polygons in ADQL/STC. Questions and recommendation.

[Francois Ochsenbein]

Hi Tom, Alberto,

Maybe you could be interested in the Region class we developped
for simbad; some javadoc can be found from 
http://cds.u-strasbg.fr/~francois/javadoc/ 
where we had effectively to define a box (its orientation
depends on the frame) and a rotatedBox (a position angle
defines the orientation of the box). We also defined a
"zonal region" (a kind of 'rectangle' where 2 'sides' are
small circles), and the elliptical region.

And about the range in longitude or right ascension: in all
our services, the longitude range is ordered, i.e.
 350..10 (between 350 and 10) is understood as "RA>=350 or RA <=10"   while
 10..350 (between 10 and 350) is understood as "RA>=10 and RA <=350" 
i.e. when the upper limit is smaller than the lower limit,
the operator becomes "or" instead of "and". No need for
a special function...

Cheers, francois

>
>Alberto Micol wrote:
>> On 24 Oct 2009, at 20:24, Tom McGlynn wrote:
>>
>>
>>> Roy Williams wrote:
>>>
>>>> It seems that the region specification does not support the RA/Dec
>>>> limits, or the Glon/Glat limits, etc etc. All polygon boundaries in
>>>> ADQL Region are great circles.
>>>> -- Is that correct?
>>>>
>>>> Therefore I assume the recommendation will say that such regions
>>>> should NOT be implemented with ADQL Region, but should be
>>>> implemented directly in the SQL query like this:
>>>>    RA between 200 and 210 and Dec between 20 and 30.
>>>> -- Is that correct?
>>>>
>>>>
>>>>
>>> I think so.  There is one issue that might make it nice to have a
>>> special function for this kind of box: the wrapping of longitude
>>> values.  E.g.,  if I want the 20x20 box from 350 to 10 degrees in
>>> lon and -10 to 10 in lat, the syntax is different than for the
>>> region from 330-350 in lon.  So it would be nice to have some syntax
>>> -- say rect -- which would allow users to specify
>>>
>>>   rect(350,10,-10,10) == rect(-10,10, -10,10) == rect(350,370,-10,10)
>>>
>>>
>>
>> That "rect"  does not seem to be equally useful when spanning across
>> the pole...
>> How do I express a rect that is centered at dec=85 and that extends 10
>> deg in dec?
>>
>> Al
>>
>
>If what you want is a box with a given angular size that happens to
>include the pole, then the current ADQL box is closer to what you want.
>However in most cases I think it won't work for you because you won't be
>able to orient the box appropriately.  A box function of the form
>
>    box(lon,lat,width,height,angle)
>
>where the last argument is new and gives a position angle for the cross
>that defines the box would address this.  I think this would be quite a
>powerful concept and might be used quite a bit.  No one has yet
>suggested use cases where the current box function, without that last
>argument, seems especially helpful.
>
>Generally I think boxes would tend to be small and would tend to reflect
>individual observations.  Rects, would tend to be much larger.  They'd
>be useful in defining things like, the region a telescope can view
>during a particular observing campaign, or a simple bound for the
>overall coverage of a survey.  It's certainly possible to do rects
>without defining a special function for them, but as I suggested above
>it's not entirely trivial to do right.
>
>    Tom
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)368 85 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)368 85 24 17
=======================================================================