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

[Tom McGlynn]

Patrick Dowler wrote:

> It is intended to be used as a constant  argument to INTERSECTS or CONTAINS 
> predicates. BOX is defined to be equaivalent to BOX in STC and I recall that 
> the reason for that (for both, in fact) is that one can transform a BOX in one 
> coordinate system into a POLYGON in another. For example, an ADQL query could
> contain
> 
> INTERSECTS( BOX('GALACTIC', 0,0,60,10), someColumn) = 1
> 
> and the TAP service could transform that to local coordinates (eg ICRS) and do 
> the query. This could also be written using REGION instead of BOX, and then 
> specifying the STC box, but the meaning/result would be the same.
>

I guess I'm still not seeing how this works, in terms of actual queries. 
  Suppose the user is interested in objects near the galactic center 
with |l| < 30 and |b| < 5.  Can they then ask for
   BOX('GALACTIC', 0, 0, 60,10)
as you've put it above?

No...  That box will not include a little bit of the region near, e.g., 
30,5.  Nor can they use
    POLYGON('GALACTIC', -5,-30, -5,30, 5,30, -5, 30)
directly but it's probably better since it includes slightly more than 
they want rather than slightly less and so they can filter out the 
excess results.  Generating a polygon that encloses the 'rect' region of 
the kind discussed elsewhere in this thread is pretty easy but it's not 
a BOX.

Ok... Maybe they are just interested in a region of the sky near l,b and 
they want this patch to be easily transformable among coordinates.  But 
if they are interested in a box rather circle, then manifestly there is 
some idea of an orientation of the box.  If I don't have that then
   CIRCLE('galactic', l,b,r) is much more natural
than
   BOX('galactic',l,b,r,r).

If they do have an orientation in mind, then unless it happens to be 
that of the underlying coordinate system (which may occasionally be the 
case but I haven't seen it), they are out of luck since BOX doesn't 
allow any others.

So I'm still unclear why one would ever want to use a box.

One suggestion that would be compatible with existing code would be
to overload BOX with a six argument version that includes the rotation 
which is set to 0 when someone uses the current five argument function.

	Tom


P.S., I don't think we should be thinking of these geometry functions as 
being used as constants in queries.  I think there could be (and ideally 
will be) lots of queries of the form

    select objects in table a from objects a, observations b where
       contains( box(b.ra,b.dec, 0.5,0.5, b.angle), point(a.ra,a.dec))=1

But to really unleash this requires a more functional box.  Doing this 
kind of query with polygons would be much more difficult.  If we don't 
improve box then probably it get written a

    select ... where
       contains(radius(b.ra,b.dec, 0.77), point(a.ra,a.dec) = 1 and
       some_modestly_complex_function_of_the_coordinate_and_angle
where the second line in the where clause truncates the circle to the 
desired box.