<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 Gregory,<div class=""><br class=""></div><div class="">I fully commend your will to finish ADQL-2.1 asap.</div><div class="">Still, one should be careful in defining things in a way that does not block developers, providers, use cases, and user’s uptake.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 24. Feb 2020, at 11:20, Gregory MANTELET <<a href="mailto:gregory.mantelet@astro.unistra.fr" class="">gregory.mantelet@astro.unistra.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
Dear DAL,<br class="">
<br class="">
In the goal to make ADQL-2.1 *finally* released, I would say that we
keep version of DISTANCE between 2 points, instead of between two
any other geometries. This latter, as Markus said, would require
more careful definitions of what should be the distance between, for
instance, a polygon and a circle (should it be between their
"centroid" or the closest distance between boundaries of each
geometry? ; this is a debate that, I think is out of scope for
ADQL-2.1).<br class=""></div></div></blockquote><div><br class=""></div><div>I do not see the need for any debate, as the world is already using one and only one definition:</div><div><br class=""></div><div>(1) the distance between two neighbouring countries, take Germany and France, is zero,</div><div>otherwise they would not be neighbouring at all ! </div><div><br class=""></div><div>(2) The definition already exists in the universally-adopted OGC standard:</div><div><i class=""> "the distance between two geometries is the shortest distance between any two points in those two geometries"</i></div><div> (see: OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common 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 class=""><div><br class=""></div><div>(3) Many DBMSes already operationally use such definition (e.g., PostGIS, SQLServer, ORACLE). </div><div class=""><br class=""></div></div><div class="">(4) Adopting any different definition would only cause confusion to everybody.</div><div class=""><div class=""><br class=""></div><div class="">(5) Adopting existing standards can only speed up our VO work.</div><div class=""><br class=""></div></div><div class="">With that definition we would be fine and ready for the future (for some of the implementations), or ready for the present (for some other implementations).</div><div class=""><br class=""></div><div class="">With the above definition, and with the grammar that I already proposed in an earlier email,</div><div class="">we are ready to proceed with no further delays to the publication of the ADQL2.1.</div><div class=""><br class=""></div><div class=""><div class="">Regarding centroids, yes, I’m in!</div><div class=""><br class=""></div><div class="">Many thanks,</div><div class="">Alberto</div></div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
However, as Pat commented, CENTROID should be allowed as valid
argument of DISTANCE. This should not cost much to add that in the
grammar. Besides, it would *indirectly* allow the computation
between two geometries by writing something like: DISTANCE(
CENTROID(POLYGON(....)), CENTROID(CIRCLE(...)) ).<br class="">
<br class="">
About the version of DISTANCE with 4 numeric arguments, I am not
especially in favor or against it. As Ger pointed it out, it is just
syntactic sugar, which, as Markus said, may introduce a bit a
complexity, and so of bugs...but I can not really anticipate which
ones. So, I fairly neutral on this point.<br class="">
<br class="">
To sum up my thoughts:<br class="">
<br class="">
<i class="">(for more readability here, I did not replace the parenthesis and
comma with their BNF equivalent)</i><br class="">
<tt class="">---------------------------------------------------------------------</tt><br class="">
<tt class=""><distance> ::=<br class="">
DISTANCE(<coord_value>, <coord_value>)</tt><tt class=""><br class="">
</tt><tt class=""> | DISTANCE(<numeric_value_expression>, </tt><tt class=""><numeric_value_expression>,<br class="">
</tt><tt class=""><numeric_value_expression>, </tt><tt class=""><numeric_value_expression>)</tt><tt class=""><br class="">
<br class="">
</tt><tt class=""><coord_value> ::= <point_value> |
<column_reference></tt><tt class=""><br class="">
</tt><br class="">
<tt class=""><point_value> ::= <point> | <centroid></tt><br class="">
<tt class="">---------------------------------------------------------------------</tt><br class="">
<br class="">
I am aware that adding <centroid> into <point_value> has
not an impact only on <distance>, but I looked in other places
where it is used and I do not see why it would be inappropriate or
error prone. Just tell me if it does.<br class="">
<br class="">
I can start a GitHub's PR with these and the suggestions of Markus,
if you want to.<br class="">
<br class="">
Cheers,<br class="">
Grégory<br class=""></div></div></blockquote></div><br class=""></div></body></html>