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

[Alberto Micol]

Furthermore, if it is true that the horizontal arm is on a parallel  
(isolatitude),
then the only great circles that are perpendicular to it are the  
meridians.
Hence the BOX will have the vertical sides actually  lying onto the  
meridians.
But in such case, if the box size is bigger than the distance to a pole,
the shape of the box will be a kind of "butterfly" with the sides  
always crossing
at the pole (exactly as the box defined in SIAP v1).

Hence a box will not at all (at the poles) resemble the footprint of  
an image.

That is _not_ nice, and probably it was not intended to be so.

The question I really have is: Am I so wrong?

Thanks for any help I will get!
Alberto


On 24 Oct 2009, at 01:05, 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!
>
> 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.
>
> That seems mathematically handy and quite fast for any database, but  
> places the
> burden on data providers that will have to change the way they store  
> coordinates.
>
> (It's a bit late here in Central Europe, I hope I got my math and  
> reasoning right!)
>
> Alberto
>