I do not believe that ELLIPSE is a well defined concept. It only exists in
the tangent plane. Given a center, minor axis, major axis, this covers
Different pixels in different projections, thus defining it as it is
meaningless. Then we need also the WCS of the projection, like those of a
FITS image. Then ELLIPSE becomes well defined WITHIN THAT CONTEXT.
Or, we can conceivably define it as a cone whose aspect ratio is warped, but then it is not an ellipse on a TAN projection in general. So, something must be sacrificed. I do not think this has been thought through, so I would like to vote against using ELLIPSE altogether in a generic sense until we clarified these issues.
--Alex
-----Original Message-----
From: owner-voql-teg-at-eso.org [mailto:owner-voql-teg-at-eso.org] On Behalf Of
Jeff Lusted
Sent: Wednesday, May 28, 2008 7:05 AM
To: voqlteg
Subject: Spec (BNF) changes parallel to the RFC
Hi Colleagues!
My apologies if I've been a little slow in replying to the RFC comments. I've made a start this morning, replying to one of Bob's points.
I've also been trying to adjust the syntax (minimally I hope) according to the comments which I think we accepted (eg: BOX, and our own internal discussion on the LATITUDE and LONGITUDE functions). Attached is a new HTML-based version of the BNF diagrams for you to examine. Here are the relevant points. I need your feedback...
(1) I've changed RECTANGLE to BOX.
<box> ::=
BOX <left_paren> <coord_sys>
<comma> <coordinates>
<comma> <side1>
<comma> <side2>
<right_paren>
<side1> ::= <numeric_value_expression>
<side2> ::= <numeric_value_expression>
BOX is now a reserved word. RECTANGLE is no longer a reserved word.
(2) I've added ELLIPSE. This was brought up by Francois Ochsenbein, and I thought that it also came up in the discussions. In our efforts to show we do our best to accommodate STC, this is the definition...
<ellipse> ::=
ELLIPSE <left_paren> <coord_sys>
<comma> <coordinates>
<comma> <radius>
<comma> <minor_radius>
<comma> <position_angle>
<right_paren>
<minor_radius> ::= <numeric_value_expression>
<position_angle> ::= <numeric_value_expression>
_Please_ let me know if this is adequate, or too much!!! ELLIPSE would become a reserved word.
(3) I've altered the name of <system_defined_function> to
<geometry_function> and moved <centroid> into the list. I've made minor
adjustments to the names for the sake of readability (basically I've
only used "function" where the expansion is a list of functions, which
fits in better with the definition of maths and trig functions, the one
exception being <user_defined_function>)...
<geometry_function> ::=
<area>
| <centroid>
| <distance>
| <latitude>
| <longitude>
| <region_function>
I've moved <centroid> here from <geometry_value_expression> to make our approach to these functions more consistent. This also entails a small change to an important definition...
<geometry_value_expression> ::= <geometry_expression> | <geometry_value>
(4) Part of this consistency is a partial redefinition of the functions so they now _all_ use <geometry_value_expression>. For example,
<centroid> ::=
CENTROID <left_paren> <geometry_value_expression> <right_paren>
<area> ::=
AREA <left_paren> <geometry_value_expression> <right_paren>
<distance> ::=
DISTANCE <left_paren> <geometry_value_expression>
<comma> <geometry_value_expression> <right_paren>
LATITUDE <left_paren> <geometry_value_expression> <right_paren>
<longitude> ::=
LONGITUDE <left_paren> <geometry_value_expression> <right_paren>
<region_function> ::= <contains> | <intersects>
and so on.
The result of this is that _all_ can use either <geometry_expression> or
<geometry_value> as parameters, the latter of which is unchanged and
defined as
<geometry_value> ::= <column_reference>.
This is consistent with other parts of the SQL definition, and makes the
approach more extensible (eg: at some future date we could change
<geometry_value> to be wider than a simple column reference, perhaps to
include the result of a scalar sub-query). Of course, we cannot enforce
full type safety with an SQL-like language (an inappropriate column
reference could always be made; vetting this would be down to analysing
metadata, which we don't pretend to cover). I think "inappropriate"
geometry expressions could have suitable defaults (eg: the area of a
point is zero) or simply fail like making an inappropriate column
reference. To my understanding this is acceptable.
Please Note. The effect of (3) and (4) is that all of these new functions are as flexible as the maths and trig functions, and can appear within a query in all the places maths/trig functions can also appear. This was _not_ the case before. I've tested by making changes within the parser, and it all seems to work.
(5) I've changed the <coordinates> definition to be more neutral, from ...
<coordinates> ::= <coord_lon> <comma> <coord_lat>
to
<coordinates> ::= <coord1> <comma> <coord2>
<coord1> ::= <numeric_value_expression>
<coord2> ::= <numeric_value_expression>
Finally, some minor points on the Spec document....
(6) Inaki, I've just fuly implemented the join syntax as outlined in the BNF diagrams in the spec...
<qualified_join> ::=>
<table_reference> [ NATURAL ] [ <join_type> ] JOIN
<table_reference> [ <join_specification> ]
I'm not sure this is the same as the text explanation, as the above makes <join_type> optional. It's a little ambiguous...
"Among the different types of joins ADQL supports qualified ones only. These are INNER and OUTER ones (LEFT, RIGHT and FULL). All of these can be NATURAL or not."
Perhaps a change to...
"Among the different types of join, ADQL supports INNER and OUTER (LEFT, RIGHT and FULL) joins. If none is specified, the default is INNER. All of these can be NATURAL or not."
(7) CONTAINS. I had a look at OpenGIS, and the intention in CONTAINS( x,y ) is that the test is for x containing y. I think we have implied it is the other way around in our examples, which makes the examples less intuitive.
(8) One extra, minor point. Within Appendix A: "An easier to navigate version of the BNF grammar can be found here". The link in the spec does not seem to work.
Well, we make progress (I hope)!
Regards
Jeff
-- Jeff Lusted tel: +44 (0)116 252 3581 Astrogrid Project mob: +44 (0)7973 492290 Dept Physics & Astronomy email: jl99-at-star.le.ac.uk University of Leicester web: http://www.astrogrid.orgReceived on 2008-05-28Z13:30:45