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

[Tom McGlynn]

Just to follow on to Francois discussion...


-- What are the vertices?

I didn't quite follow -- it's hard in text without diagrams, but it 
wasn't obvious to me how to get the rotation matrix that Francois uses.  
While the transformation from vertex to center is just two rotations, I 
think only one of them is a simple rotation by a box dimension around   
coordinate axis.  E.g., suppose I have a box with width a and height b 
centered at 0,0.  Then the I could first rotate around the y axis by b 
to move (0,0) to (0,b).  However the second rotation is not a rotation 
around the z axis but an axis offset from z by b degrees.  Similarly if 
I try to along the z axis first by a to transform (0,0) to (a,0), then 
it's true that the second rotation is just in along the y axis, but I 
don't know it's dimension: it's not b.

My approach -- and it may be that it ultimately the same as Francois' 
under the covers  and I don't see it-- is to recognize that vertices are 
points on the sphere that whose unit vectors are perpendicular to the 
centers of the great circles (i.e., the points on the sphere 90 degrees 
from the great circle).  All points on the great circle have unit 
vectors perpendicular to the unit vector of the center.  To find the 
intersection of two great circles, find the points perpendicular to 
centers of both.

It's easy to find the centers of great circles which define the edges of 
a box centered at (0,0) with size (2a,2b) so we'll do that...

Two of the box boundary circles are arcs on the meridians at longitude a 
and -a.  These have centers at (90+a,0) and (90-a,0). Similarly the top 
and bottom boundaries have centers along the prime meridian/date great 
circle at (180,90-b) and (180,b-90).

If we now consider the unit vectors corresponding to these centers and 
require that they be perpendicular to our vertex unit vector we get

    x = 1/(sqrt[1+tan2(a)+tan2(b)])
    y = tan(a)/x
    z = tan(b)/x

[where tan2(x) is just the square of the tangent]

If d is the latitude of the vertices of the box, which is the only 
unknown (since two of the boundaries are meridians with constant longitude)
   sin(d) = z    or
   d = asin(tan(b)/sqrt(1+tan2(a)+tan2(b)))
and the coordinates of the vertices are the four points at (+/-a,+/-d).

Given a solution around 0,0 we can rotate to the actual central 
coordinates of the box to get a solution
anywhere.

What is the shape...

I fully agree with Francois description below (which suggests that I 
misunderstood his derivation since
at least qualitatively they are the same).  Squares grow into a 
hemisphere and for sizes larger tan 90
degrees they become non-convex figures which exclude a square box 
centered opposite the center of the actual
box.

Narrow rectangles are more problematic.  Assuming a constant smallish 
height, then as the width exceeds a radian, the box becomes eye shaped 
until at width 180 the top and bottom boundaries intersect giving a pie 
slice between two meridians that Francois described.

I think there is a discontinuity at that point.  If the width is > 180, 
then I believe the math is telling us that the box is
a region which includes the entire sphere except a narrow box around the 
original box's anticenter.  That's a bit painful...


What to do...

Personally I don't think boxes as defined are useful.  As we see they 
have peculiar properties for large regions.  I think they could be 
useful for small regions, e.g., to represent fields of view in a simple 
and transformable fashion.  Getting the boundaries of an image near the 
poles is a bit painful.  It's not an enormous problem but with boxes it 
would be really simple to represent.   However in all of the cases that 
I'm thinking of, boxes would need to be able to be rotated with respect 
to the coordinates, which is not currently supported.  To make boxes 
useful I'd say do one of two things...
 - add a position angle to the box that allows rotation with respect to 
coordinates.
 - redefine boxes to represent the pair of ranges in coordinates (a la 
PgSphere).

I'd see users finding both of those to be helpful.  Or we could leave 
things alone.  In this case boxes will simply not be used much which is 
not an awful fate. However in this case I think that it is essential 
that our documentation note very prominently and explicitly that boxes 
do not correspond to coordinate ranges.

    Tom


Francois Ochsenbein wrote:
> Well, a box can't be a limit in RA/Dec is you are far for the Equator;
> having a pole within a box would invitably turn the box into a small
> circle...
>
> I can't either understand the STC definition of a polygon where 
> a vertex may optionnaly be a SmallCircle object: while joining 
> point A to point B on a great circle is always possible, it's not
> true for a small circle depending on the pole's position.
> Moreover joining point A to point B is a joined property of 
> the 2 vertices, but Arnold's definition means that the polygon 
> has a different shape if you describe the polygon in the opposite
> order (great circle lines may turn into small circle lines and
> vice-versa). I understand that Arnold wants to describe in a 
> single definition both types of lines (great and small circles),
> but these are really different geometries.
>
> About the BOX vs polygon, my understanding of STC definition is that
> the box sides are great circles (for SPHERICAL flavor) since there
> is no possibility of defining smallCircle vertices here.
> And compared to the polygon, the 'inside' is perfectly defined
> (the part of the sphere which contains the center is the 'inside').
>
> About the BOX orientation: it is undefined only if the box center
> is one of the poles.
>
> The four vertices of a box can be computed in a rather straightforward
> way if you use the cartesian coordinates 
>   (x=cos(Dec)cos(RA), y=cos(Dec)sin(RA), z=sin(Dec), x^2+y^2+z^2=1)
> and the rotation matrix between the (RA=0,Dec=0) point and the
> box center, which should give the cartesian coordinates of the
> vertices
>    x = x0*dx -i*(y0/r0)*dy -j*(x0/r0)*z0*dz
>    y = y0*dx +i*(x0/r0)*dy -j*(y0/r0)*z0*dz
>    z = z0*dx               +j*r0*dz
> if (x0, y0, z0) are the cartesian coordinates of the center, 
> r0=sqrt(x0^2+y0^2), (i,j) are +/-1 to describe the 4 vertices, 
> and the dx dy dz are derived from the box size (a x b)
>   dx=cos(b/2)cos(a/2), dy=cos(b/2)sin(a/2), dz=sin(b/2)
> [does not work when r0=0, i.e. centered on a pole, in which
> case the orientation of the box in undefined]
>
> In the peculiar case dy=0 or dz=0 (one box size is pi radians)
> you got only 2 vertices, and it's hard to view this figure
> (similar to the area between 2 meridians) as a 'polygon';
> if a=b=pi (square of 180deg on each 'side') the 'box' becomes
> an hemisphere, as Tom pointed out (the vertices are opposite).
> With a=b=2pi (360deg), gou get a single vertice (dx=-1, dy=dz=0,
> the opposite of the box center) -- that single vertex represents
> the whole sphere (a 'polygon' with a single point?)
>
> Should we recommend that a 'box' is restricted to size<180deg ?
>
> Have a nice week-end :-)
> Francois
>
>   
>> I believe that both BOX definitions would have advantages and clearly
>> very different uses:
>>
>>  - Using "RA-Dec" BOXes one could tile the entire sky without any overlap
>> and, as Tom points out, they are extremely simple to implement.
>>
>>  - A "great circle" BOX could represent a simple region that can describe
>> the coverage of a rectangular detector with WCS TAN projection.
>>
>> Considering that STC/s is part of the ADQL geometry specs, whose polygons
>> are apparently restricted to great circles, one could argue that BOX
>> should be interpreted in the "RA-Dec" sense for simplicity, and use the
>> STC/s polygon for the other case.
>>
>> Alternatively, one could define the BOX to be a shortcut to the STC/s
>> polygon, and implement RA-Dec constraints by explicitely spelling them out
>> in the query.
>>
>> I don't feel strongly either way but perhaps the latter is a bit more
>> appealing to me, because this way a simple and common geometry constraint
>> (TAN coverage of, say, a CCD) could be described in ADQL without
>> supporting the more advanced STC/s constructs that might be a little more
>> challenging for some implementations in terms of parsing and query
>> optimization.
>>
>> Cheers, T.
>>
>> P.S. Of course, one could also just have both boxes in ADQL with separate
>> keywords.
>>
>>
>> On Fri, 23 Oct 2009, Tom McGlynn wrote:
>>
>>     
>>> Alberto Micol wrote:
>>>       
>>>> On 23 Oct 2009, at 21:19, Arnold Rots wrote:
>>>>
>>>>
>>>>         
>>>>> 4.5.1.5 Box
>>>>> A Box is a special case of a Polygon, defined purely for  convenience. It
>>>>> is
>>>>> specified by a center position and size (in both coordinates)  defining a
>>>>> cross
>>>>> centered on the center position and with arms extending, parallel to  the
>>>>> coordinate axes at the center position, for half the respective  sizes on
>>>>> either side.
>>>>> The box?s sides are line segments or great circles intersecting the  arms
>>>>> of the
>>>>> cross in its end points at right angles with the arms.
>>>>>
>>>>>           
>>>> My trouble is with the sentence that  the arms extend "parallel to the
>>>> coordinate axes".
>>>> "Parallel" to the equator cannot be a great circle unless it is the
>>>> equator itself. Hence:
>>>> Does that mean that the I should measure the size of the "horizontal"  arm
>>>> along
>>>> the small circle parallel to the equator?
>>>> If this is correct, then a size of 180 deg is an hemisphere if and  only if
>>>> the centre is placed
>>>> on the equator.
>>>>
>>>> I appreciate some help, thanks!
>>>>
>>>>
>>>>         
>>> Hi Alberto,
>>>
>>> I understood this to mean that the horizontal arm goes along great circle
>>> which has an apex (highest latitude, or lowest
>>> if the point is in the southern hemisphere) at the point.  So the great
>>> circle is 'parallel' to the equator but only
>>> instantaneously at that point  However I wouldn't mind one of the experts
>>> chiming in here.
>>>
>>>       
>>>> Then, regarding the usefulness of a BOX made of great circle arcs:
>>>> that is useful because to find if a point is inside or outside such BOX
>>>> it is just matter to compute the scalar product of the vector  representing
>>>> the point
>>>> and the 4 vectors representing the half-spaces of the 4 box sides.
>>>>
>>>> Of course this means that it will no longer be possible to use (ra,  dec)
>>>> as we are used to,
>>>> as in:  ra BETWEEN this AND that AND dec BETWEEN d0 AND d1
>>>> and instead we have to go to a vectorial representation of the sky
>>>> coordinates.
>>>>
>>>>
>>>>         
>>> My problem is that as far as I can see, the problem that the astronomers want
>>> to answer will be phrased
>>> in terms of limits on RA and Dec so that even though it might be
>>> mathematically handy it's not necessarily relevant
>>> to the problems we want to solve.   In any case there's nothing special about
>>> the box here.  It's true for any
>>> (convex?) polygon isn't it?
>>>
>>> Tom
>>>
>>> P.S.  I think I've gotten the equations for the vertices of a box (assuming
>>> my interpretation above is correct).  The derivation
>>> was pretty easy once I abandoned trying to do things using pure geometry and
>>> attacked it using the centers of the great circles and
>>> analytic geometry.  I'll try to post it somewhere tomorrow.
>>>
>>>
>>>       
> =======================================================================
> 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
> =======================================================================
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20091024/5827a13a/attachment-0003.html>