<div dir="ltr"><div class="gmail_default" style="font-size:small">I agree with the basics:<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">DISTANCE(<point>, <point>)</div><div class="gmail_default" style="font-size:small">DISTANCE(<number>, <number>, <number>, <number>) -- for convenience</div><div class="gmail_default" style="font-size:small">plus suitable conversion/restriction when a column reference is used in place of a value</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] the prose is probably there because CENTROID returns a <point>, eg DISTANCE(CENTROID(foo), ...)<br></div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 19 Feb 2020 at 07:16, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DAL,<br>
<br>
Current ADQL says:<br>
<br>
Functions like AREA, COORD1, COORD2 and DISTANCE accept a<br>
geometry and return a calculated numeric value.<br>
<br>
The specification defines two versions of the DISTANCE function, one<br>
that accepts two geometries, and one that accepts four separate numeric<br>
values, both forms return a numeric value.<br>
<br>
Both statements would indicate that DISTANCE should accept general<br>
geometries, i.e., including circles and polygons. <br>
<br>
The later definition of DISTANCE then says<br>
<br>
The specification defines two versions of the DISTANCE function,<br>
one that accepts two POINT values, and a second that accepts four<br>
separate numeric values.<br>
<br>
-- which is clear enough, had it not been for the previous statement,<br>
and the later statement<br>
<br>
If the geometric arguments are expressed ...<br>
<br>
which might again be understood as saying the arguments can be more<br>
general.<br>
<br>
Finally, the grammar says, for the geometry case:<br>
<br>
DISTANCE <left_paren> <coord_value> <comma> <br>
<coord_value> <right_paren><br>
<br>
where<br>
<br>
<coord_value> ::= <point> | <column_reference><br>
<br>
I *think* all this works out to say that over and above the grammar,<br>
for distance there's the additional constraint that column_reference<br>
must be POINT-typed.[1] <br>
<br>
Being general here is a pain in the neck (actually, that's why I ran<br>
into this question). For one, you'll need to define distance<br>
much more carefully for such geometries, and if (as I think we ought<br>
to) we chose "minimum of distances of between all points in arg 1 and<br>
arg 2", I doubt we'll see many correct implementations of that. Also<br>
I'll want to map a lot of DISTANCE calls into contains(point,<br>
circle) statements (because that's much easier on the query planner),<br>
and that's a pain if one of the points could actually be, say, a<br>
polygon.<br>
<br>
So... do we agree that DISTANCE only accept POINT-s?<br>
<br>
If so, I'd suggest to just drop the sentence:<br>
<br>
Functions like AREA, COORD1, COORD2 and DISTANCE accept a<br>
geometry and return a calculated numeric value.<br>
<br>
Then change<br>
<br>
The specification defines two versions of the DISTANCE function,<br>
one that accepts two geometries, and one that accepts four<br>
separate...<br>
<br>
to<br>
<br>
This specification defines two versions of the DISTANCE function,<br>
one that accepts two POINTs, and one that accepts four<br>
separate...<br>
<br>
And then add in 4.2.16 in some appropriate location something like<br>
<br>
Note that when <column reference>s[2] are passed into DISTANCE, the<br>
operation is only defined for POINT-typed values. Behaviour for<br>
other geometries is undefined at this point (but may be defined<br>
later).<br>
<br>
Would anyone veto a PR to this effect? Would anyone prefer something<br>
completely different? Would anyone volunteer for doing the PR?<br>
<br>
-- Markus<br>
<br>
[1] Incidentally, the grammar rules are incompatible with the<br>
statement in the 4.2.16 that "[t]he DISTANCE function may be applied<br>
to any expression that returns a geometric POINT value"; I see why it<br>
was put in, but unless we fix the grammar, we should remove the<br>
prose.<br>
<br>
[2] or <geometry_value_expression>s, depending on how you think about<br>
[1]<br>
</blockquote></div>