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
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.
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