I agree with Alex on this. Adding a poorly defined concept at this point is not a good idea.
Pat
On 2008-5-28 04:32, Alex Szalay wrote:
> 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> ::=
> 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
-- 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.)Received on 2008-05-28Z18:42:40