<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Dear DAL,<div class=""><br class=""></div><div class="">At ESO we use DISTANCE( geometry, geometry ),</div><div class="">where geometry can be a point, a circle, a polygon, a union of polygons, a centroid, etc.<div class=""><div class=""><br class=""></div><div class="">The OGC standard:&nbsp;</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>OpenGIS®&nbsp;Implementation Standard for Geographic&nbsp;information - Simple&nbsp;feature access - Part 1: Common&nbsp;architecture</div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>available at: <a href="http://portal.opengeospatial.org/files/?artifact_id=25355" class="">http://portal.opengeospatial.org/files/?artifact_id=25355</a></div></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>in the paragraph:&nbsp;6.1.2.4 Methods that support spatial analysis</div><div class="">defines DISTANCE (along with, intersection, unions, etc).</div><div class=""><br class=""></div><div class="">No point in reinventing the wheel: let’s just take that definition and reuse it.</div><div class="">I quote it here:</div>
                
        
        
                <div class="page" title="Page 17">
                        <div class="layoutArea">
                                <div class="column">
                                        <ul style="list-style-type: none" class="">
                                                <li class=""><p class=""><span style="font-size: 10.000000pt; font-family: 'Arial'; font-weight: 700" class="">Distance </span><span style="font-size: 10.000000pt; font-family: 'ArialMT'" class="">(anotherGeometry: Geometry):Double — Returns the shortest distance between any two Points in
the two geometric objects as calculated in the spatial reference system of </span><span style="font-size: 10.000000pt; font-family: 'Arial'; font-style: italic" class="">this </span><span style="font-size: 10.000000pt; font-family: 'ArialMT'" class="">geometric object. Because the
geometries are closed, it is possible to find a point on each geometric object involved, such that the distance
between these 2 points is the returned distance between their geometric objects.&nbsp;</span></p></li></ul></div></div></div><div class=""><div><br class=""></div><div>Regarding the grammar, something like this would do:</div><div><br class=""></div><div>DISTANCE &lt;left_paren&gt; &lt;geometry_value_function&gt; &lt;comma&gt;&nbsp;&lt;geometry_value_function&gt; &lt;right_paren&gt;<br class=""><br class=""></div><div>where, though, I would ask to modify the current definition of &lt;geometry_value_function&gt;,</div><div>which is:</div><div><pre xmlns="http://www.w3.org/1999/xhtml" class=""><span class="verbline">&lt;geometry_value_function&gt;&nbsp;::=
</span><span class="verbline">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;box&gt;
</span><span class="verbline">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&lt;centroid&gt;
</span><span class="verbline">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&lt;circle&gt;
</span><span class="verbline">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&lt;point&gt;
</span><span class="verbline">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&lt;polygon&gt;
</span><span class="verbline">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&lt;user_defined_function&gt;</span></pre><div class="">probably removing the deprecated (is it still?) &lt;box&gt;&nbsp;</div><div class="">and adding:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>| &lt;union_of_geometries&gt;</div><div class=""><br class=""></div><div class="">with:</div><div class=""><br class=""></div><div class=""><pre xmlns="http://www.w3.org/1999/xhtml" class=""><span class="verbline">&lt;union_of_geometries&gt;&nbsp;::=
</span><span class="verbline">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UNION&nbsp;&lt;coord_sys&gt; </span>&lt;left_paren&gt;</pre><pre xmlns="http://www.w3.org/1999/xhtml" class=""><span class="verbline"><span class="Apple-tab-span" style="white-space:pre">                </span>&lt;geometry_value_function&gt;</span></pre><pre xmlns="http://www.w3.org/1999/xhtml" class=""><span class="verbline"><span class="Apple-tab-span">                </span>{&nbsp;</span>&lt;geometry_value_function&gt; } ?</pre><pre xmlns="http://www.w3.org/1999/xhtml" class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    &nbsp;&lt;right_paren&gt;</pre></div></div><div>Alberto</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On 19. Feb 2020, at 16:14, Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear DAL,<br class=""><br class="">Current ADQL says:<br class=""><br class=""> &nbsp;Functions like AREA, COORD1, COORD2 and DISTANCE accept a<br class=""> &nbsp;geometry and return a calculated numeric value.<br class=""><br class=""> &nbsp;The specification defines two versions of the DISTANCE function, one<br class=""> &nbsp;that accepts two geometries, and one that accepts four separate numeric<br class=""> &nbsp;values, both forms return a numeric value.<br class=""><br class="">Both statements would indicate that DISTANCE should accept general<br class="">geometries, i.e., including circles and polygons. &nbsp;<br class=""><br class="">The later definition of DISTANCE then says<br class=""><br class=""> &nbsp;The specification defines two versions of the DISTANCE function,<br class=""> &nbsp;one that accepts two POINT values, and a second that accepts four<br class=""> &nbsp;separate numeric values.<br class=""><br class="">-- which is clear enough, had it not been for the previous statement,<br class="">and the later statement<br class=""><br class=""> &nbsp;If the geometric arguments are expressed ...<br class=""><br class="">which might again be understood as saying the arguments can be more<br class="">general.<br class=""><br class="">Finally, the grammar says, for the geometry case:<br class=""><br class=""> &nbsp;DISTANCE &lt;left_paren&gt; &lt;coord_value&gt; &lt;comma&gt; <br class=""> &nbsp;&nbsp;&nbsp;&lt;coord_value&gt; &lt;right_paren&gt;<br class=""><br class="">where<br class=""><br class=""> &nbsp;&lt;coord_value&gt; ::= &lt;point&gt; | &lt;column_reference&gt;<br class=""><br class="">I *think* all this works out to say that over and above the grammar,<br class="">for distance there's the additional constraint that column_reference<br class="">must be POINT-typed.[1] &nbsp;<br class=""><br class="">Being general here is a pain in the neck (actually, that's why I ran<br class="">into this question). &nbsp;For one, you'll need to define distance<br class="">much more carefully for such geometries, and if (as I think we ought<br class="">to) we chose "minimum of distances of between all points in arg 1 and<br class="">arg 2", I doubt we'll see many correct implementations of that. &nbsp;Also<br class="">I'll want to map a lot of DISTANCE calls into contains(point,<br class="">circle) statements (because that's much easier on the query planner),<br class="">and that's a pain if one of the points could actually be, say, a<br class="">polygon.<br class=""><br class="">So... do we agree that DISTANCE only accept POINT-s?<br class=""><br class="">If so, I'd suggest to just drop the sentence:<br class=""><br class=""> &nbsp;Functions like AREA, COORD1, COORD2 and DISTANCE accept a<br class=""> &nbsp;geometry and return a calculated numeric value.<br class=""><br class="">Then change<br class=""><br class=""> &nbsp;The specification defines two versions of the DISTANCE function,<br class=""> &nbsp;one that accepts two geometries, and one that accepts four<br class=""> &nbsp;separate...<br class=""><br class="">to<br class=""><br class=""> &nbsp;This specification defines two versions of the DISTANCE function,<br class=""> &nbsp;one that accepts two POINTs, and one that accepts four<br class=""> &nbsp;separate...<br class=""><br class="">And then add in 4.2.16 in some appropriate location something like<br class=""><br class=""> &nbsp;Note that when &lt;column reference&gt;s[2] are passed into DISTANCE, the<br class=""> &nbsp;operation is only defined for POINT-typed values. &nbsp;Behaviour for<br class=""> &nbsp;other geometries is undefined at this point (but may be defined<br class=""> &nbsp;later).<br class=""><br class="">Would anyone veto a PR to this effect? &nbsp;Would anyone prefer something<br class="">completely different? &nbsp;Would anyone volunteer for doing the PR?<br class=""><br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- Markus<br class=""><br class="">[1] Incidentally, the grammar rules are incompatible with the<br class="">statement in the 4.2.16 that "[t]he DISTANCE function may be applied<br class="">to any expression that returns a geometric POINT value"; I see why it<br class="">was put in, but unless we fix the grammar, we should remove the<br class="">prose.<br class=""><br class="">[2] or &lt;geometry_value_expression&gt;s, depending on how you think about<br class="">[1]<br class=""></div></div></blockquote></div><br class=""></div></div></div></body></html>