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

[Tom McGlynn]

Patrick Dowler wrote:
> On Friday 23 October 2009 11:28:43 Tom McGlynn wrote:
>> In trying to implement the geometry elements of ADQL, I was a bit
>> surprised when I finally read the definition of Box carefully.  I had
>> assumed that it corresponded to a range in both coordinates.   That's
>> what the PgSphere Box is.   However an ADQL box is a polygon, so it's
>> sides are all great circles.  If I've read this and done my geometry
>> properly then, e.g.,  an ADQL box with a size of 180 degrees on both
>> sides is in fact the hemisphere centered on the center of the box, i.e.,
>> a box and a circle are the same for that radius.  The area of the box is
>> independent of the center of the box and depends only on the width fields.
> 
>>From what Arnold wrote, the sides of an STC polygon have to be less than 180 
> deg; for larger polygons you have to include an extra vertex. From that I 
> would extrapolate that boxes have to be less than 180 deg width and height, 
> although that limitation is not expressed in the ADQL spec.
> 

The sides of a box with widths of 180 degrees are only 90 degrees (i.e.,
they divide a great circle up).  That's the longest the sides of a box
can be.  Large boxes have smaller sides...  So I don't think there's any 
limit there.  Given the prescription defining boxes there's no upper 
limit to the width though I've not looked at the STC in detail.

>> For small boxes, where spherical distortions and projections can be
>> ignored, this definition of  a box might be a reasonable approximation
>> to the field of view of an observation.  Still, since an ADQL box must
>> be aligned with the coordinate axes, it's not really general enough for
>> that kind of use.  It needs a positional angle or some such.  I guess
>> one might hack the coordinate system element to address this, but I
>> don't think that's appropriate.
> 
> I think for field of view one has to use polygon directly rather than box, just 
> because of the axis alignment issue. And yes, I agree that for most 
> observations the projections can be ignored.
>> So my question is: What is a box intended to be used for?
> 
> 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
> 

I understand how it can be used in ADQL, but where does this box come 
from in the query.  Coordinate range boxes are very common, but that's
not what we have here -- and it's not at all clear to me that it's
especially easy to convert a coordinate range box to this version.  On 
the other hand it's pretty easy given a range in to find a polygon that
encloses the range.

So again, what kind of use case is there for specifying a box of this kind?

> 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.
> 
>> P.S., If I may be permitted a second question. Given that a box is
>> special case of polygon, then can I transform from one to the other?
>> E.g., given a box at (a,b) with widths (c,d), what are the coordinates
>> of the corners of the box.
> 
> Yes, you can transform but I haven't got there yet either :)
> 
Spherical geometry gives me a headache!

>> P.P.S.,  This points out an ambiguity in the definition of polygons in
>> ADQL.  The definition requires only the vertices of the polygon, to
>> create a boundary the divides the sphere into two regions.  However it
>> doesn't say which of the two regions is 'inside'.  This is fairly clear
>> in the plane, where one region is always finite and the other always
>> infinite.  For large regions on the sphere there is no such obvious way
>> to distinguish regions.  E.g., consider the polygon:
>>
>>      POLYGON('ICRS GEOCENTER', 0,0,  120,0, 240,0)
>>
>> This is a 'triangle' consisting of three 120 degree segments of the
>> equator.  Does it include the northern or southern hemisphere?
> 
> ADQL specifies a correspondence with STC concepts, and STC says it "in" is to 
> the left of the segments, celestial coordinates are left-handed, so I think 
> that means it is the north... (N is left of the segments, looking out from the 
> centre).
> 
>> I don't see any obvious resolution to this issue -- maybe allow a
>> specification of a point that is inside the polygon?
> 
> Is the above sufficient? I admit it is pretty thin and one has to look around 
> alot.
> 

It's fine in terms the math, but it says to me that there is a major 
hole in the definition of polygons in ADQL.  Half the time people are 
going to specify polygons in the wrong order.  This has to be specified 
right up front in the ADQL document it cannot be hidden somewhere else. 
  I don't know if it's an approach that users will find congenial. This 
is something that gets exposed to a lot of people.  A diagram would 
probably be the best explanation.  [As well as noting that
reversing the order gives you the complement region which might 
occasionally be useful.]


Thanks for the help sorting things out.

	Tom