REGION

Patrick Dowler patrick.dowler at nrc-cnrc.gc.ca
Fri May 4 14:33:17 PDT 2007


note: I had to violate my one-screen email limit on this one, but it is 
a "report" :)

Benjamin and I exchanged a few emails off-line about region, and came up with 
this preferred format for expressing a condition:

   something OVERLAPS REGION("...")

where something is a column name or alias from the table, OVERLAPS is an 
operator, and REGION("...") is thus a literal value. REGION is a reserved 
word used to form literals (above) and to declare the type of "something". 
That is, a TAP service would say that there is a column of type REGION and 
that tells the user exactly how to formulate the condition. 

We considered other reserved words for the operator (INTERSECT, IN) but 
discounted IN because it implies complete inclusion which we thought it not 
the general meaning when both the column and the literal are extended regions 
(rather than points). INTERSECT in SQL is used to mean "set intersection" (if 
I recall) so this would not be so bad if you think of a region as the "set of 
all points" within a boundary. Using INTERSECT would mean overloading the 
meaning (ie it means something special if the arguments are regions). We 
nominally adopted OVERLAPS (although the term does appear in the SIA 1.0 
document at least). In geometry, I think INTERSECT is the general term one 
would use and it has all the correct implications whether you are talking 
about points, lines/segments, curves, or arbitrary shapes. We also looked at 
but rejected the PostgreSQL overlaps operator && as being obtuse.

Since I prefer with the trailing S, OVERLAPS seems slightly better (than 
INTERSECT). Some other reserved word might be better, but overlap is suitably 
general (it also appears in the SIA 1.0 doc and means the same thing there as 
here).

As for STC, it is just the (one?) way to specify the REGION literal. That is, 
STC says what to put in the string "...".

** Summary **

REGION is a datatype and literals are REGION("...") where ... is specified by 
STC. We add an operator OVERLAPS that is used between two REGIONs (typically 
a column of type REGION and a literal). It should work for columns of energy 
and time or whatever else is in STC. A TAP service declares (logical) columns 
of type REGION to say exactly where/how the OVERLAPS operator can be used 
with no ambiguity. 

** sales pitch **

* multiple region columns in table or via join

You can have multiple REGION columns in a table (in theory) and there is no 
need to say that 2 or more columns go together (eg ra and dec): you just have 
a column like "position" of type REGION. In an observation catalog you could 
in principle have columns like "bounds" and "center" and "target_position" 
all of type REGION and all with different values. 

* separate REGION output from query capability:

A TAP service could in principle have columns of type REGION (for output) and 
yet not support the OVERLAPS operator. I think it is good to decouple this as 
all DBs can store them but not all can do decent spatial querying. It is up 
to the TAP service to decide.

* energy and time axes (intervals):

I realised (but didn't express to Benjamin so he hasn't see this) that this 
actually works as is for the energy and time axes that STC also covers. You 
can declare a column named energy (for example) of type REGION, and then use 
STC to write the literal (interval or single value) and thus form a condition 
that is valid. Thus, one should be able to use 

   energy OVERLAPS REGION("<serialised STC energy region>")

as well. The column metadata (utype) would indicate what kind of literal 
(which STC coordinate axis) to use.

Alex mentioned a few things, 3 of which fit in fine and the 4th -- expressing 
unions and intersections and such -- we thought maybe too much for the query 
language, but could be discussed.

-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)



More information about the voql-teg mailing list