Hi Jeff,
Just a few comments on the changes:
For all these functions, the units of the arguments and of the returned value should, as well as their valid range of values, should be defined, too.
Just a last remark: all these regions are rather complex, and if the 'coordinate system' is allowed to be any of the the STC-defined ones, it will be a nightmare to combine all these regions in a query; wouldn't it be simpler, and moreover more efficient, to require these regions defined in a unique coordinate system (ICRS) ? In other terms, since regions defined in some coordinate system can be transformed into ICRS-defined regions, wouldn't it be simpler to ask the _application_ to formulate a query implying positions and/or regions in the ICRS, rather than asking all _data servers_ to transform the ADQL queries into ICRS-defined ones ? This freedom on the coordinate system looks quite similar to the question of units: the trigonometric functions assume their arguments are expressed in radians, and do not propose additional argument(s) to specify the units of the arguments...
--Francois
>
>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> ::=
> 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.org
>
Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois-at-astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 32 ================================================================================Received on 2008-05-28Z19:26:55