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

[Patrick Dowler]

On Friday 23 October 2009 16:56:30 Alberto Micol wrote:
> 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?

I think that is correct and it is the intent for ADQL BOX to be equivalent or 
a subset of STC box; it is designed to be used as a constant in ADQL queries, 
not a datatype you actually store in the DB. 

Since BOX is axis-aligned, it is not generally useful for field of view of 
observations anyway. For that you would use polygons (great circle edges are a 
decent approx for modest sizes where projection effects are small-ish) or if 
you really wanted to be fancy you would describe them with a more 
sophisticated STC region. 

Specifically to TAP, if you have spatial bounds stored in a database and you 
expose that column via TAP, you would specify the datatype (in the TAP_SCHEMA) 
as adql:REGION and you would also specify that value for the xtype if the 
column was selected. The values of the column would be STC-S regions with only 
a position sub-phrase (iirc, limited to great circle edges). On the 
implementation side: using pg_sphere, one could use spoly as the column 
datatype (great circle edges) and write such values as STC-S strings. So, both 
ADQL and STC, and therefore TAP, limit you to about the same spot: circle or 
shapes with great circle edges. 

Note that postgresql+pg_sphere has the same limitations (except sbox, so have 
to use spoly directly); I also found that both STC-S and pg_sphere are limited 
to simple polygons and do not support unions of disjoint regions or holes 
inside polygons. However, our metadata (observation FOV) does have polygons 
with disjoint shapes and holes, so I have to figure out how to deal with 
that...


-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7