<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Dear Alberto,<br>
<br>
<br>
<div class="moz-cite-prefix">On 25/02/2020 10:43, alberto micol
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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>
</blockquote>
<br>
<br>
I completely agree. But we should also be careful to the existing
implementations. [which leads me to the points below]<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<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="" moz-do-not-send="true">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>
</div>
</blockquote>
<br>
<br>
PostGIS and the geometries of SQLServer are not yet used by every
databases in the VO, and so is the OGC standard.<br>
<br>
If I take my personal case as example: I am using PostgreSQL +
PgSphere but not PostGIS (maybe I should, that's something to think
of....but not now). PgSphere is used by other major TAP services.
However, it does not allow the computation of distance between
anything else than circles and points.<br>
<br>
Changing that can not be done easily on the implementation side, and
one should think of how to define that properly in ADQL-x.x so that
existing implementations have a way to deal with such new
possibilities (the most reasonable would probably be to throw an
error if a distance between 2 complex geometries is not supported).<br>
<br>
If we especially want to adopt the OGC standard in ADQL, I suspect
we should do it for all geometries and geo. functions, and not only
a partial implementation with just DISTANCE: either we do it
completely or we don't, but not a partial implementation. Currently
I do not know if everything in ADQL is compatible with the OGC
standard, and because of that, I prefer to be careful and wait a bit
in order to study in details this evolution, rather than rushing
into it with the goal in mind to release ADQL-2.1 around May this
year.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<div 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 ! <br>
</div>
</div>
</div>
</blockquote>
<br>
<br>
I agree.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<div 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="" moz-do-not-send="true">http://portal.opengeospatial.org/files/?artifact_id=25355</a> )</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
It sounds interesting. It should definitely be something to think of
for the future of ADQL. As I said, if we do so, we would probably
have to review all other geometries to make everything consistent.<br>
<br>
Besides, doing so will probably lead to another (annoying but
unfortunately necessary) question: ADQL-2.2 or ADQL-3.0? (and I am
not starting this discussion here)<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<div class="">
<div>
<div class="">
<div class="">
<div>(3) Many DBMSes already operationally use such
definition (e.g., PostGIS, SQLServer, ORACLE). <br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
...and some existing databases (and extensions such as PgSphere)
behind TAP services would have to evolve to follow such
standard...that may take (unfortunately) time.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<div class="">
<div>
<div class="">
<div class="">(4) Adopting any different definition would
only cause confusion to everybody.</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
...it would be confusing only to people already using such
geometries in databases....which may not be the case for the
majority of our users.<br>
But yes, I agree, it would be much better to follow an existing
worldwide standard.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<div class="">
<div>
<div class="">
<div class="">
<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>
</div>
</div>
</blockquote>
<br>
<br>
To conclude my thoughts, I would propose that the possibility to
support the OGC standard should be postponed to the next version of
ADQL (2.2 or 3.0). Do not think that I do not like the idea....it is
just that I prefer an evolution of ADQL as smooth as possible,
otherwise we risk to break some existing related services and we
definitely do not want that.<br>
<br>
Cheers,<br>
Grégory<br>
<br>
<br>
PS: I will report everything said in this email thread in a GitHub
issue so that we do not forget and that we can continue this
discussion in future.<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com">
<div class="">
<div>
<div class="">
<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>
</blockquote>
<br>
</body>
</html>