<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="">In your answer you spent quite some time on the idea of supporting the OGC standard. </div><div class="">As a conclusion you said (I paraphrase) that it would take long to support OGC hence we do not change the definition of the distance ADQL function.</div><div class=""><br class=""></div><div class="">But that was not at all what I was saying!</div><div class=""><br class=""></div><div class="">I mentioned the OGC standard in my second bullet item, as an example, to state that the definition of distance between two geometries has been already defined, and there is one and only one definition used by the entire world, Hence there is no need to debate on its definition. Far from me the idea of adopting the entire OGC standard (well not at this point in time)!</div><div class=""><br class=""></div><div class="">When I said, and only in my last bullet item: "(5) Adopting existing standards can only speed up our VO work.”, that was a generic statement always good to keep in mind. But I agree that I should have written “Adopting existing standard definitions can only speed up our VO work” instead. I was only referring to the definition of “distance” as Markus was thinking of other possible distances than what normally used.</div><div class=""><br class=""></div><div class=""><div class="">A standard cannot be based on what pgsphere can or cannot do.</div><div class="">Let’s not block the VO development because some (oldish) software component cannot do better.</div></div><div class=""><br class=""></div><div class="">My conclusions are:</div><div class=""><ul class=""><li class="">The definition of distance between two geometries is well-defined and used world-wide</li><li class="">There is no reason to think of a new ADQL, version 2.2 or 3.0, ADQL2.1 can be achieved in May.</li><li class="">It is just only matter of allowing who can do more to do more. </li><li class="">If old implementations cannot change, well, they won’t. an error message will be shown; it is matter of documenting this in the ADQL2.1 standard.</li><li class="">I have already provided all is needed, including definition, and small grammar changes, for a speedy implementation of “distance” in ADQL2.1. Nothing else is needed.</li></ul><div class="">Cheers,</div></div><div class="">Alberto</div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25. Feb 2020, at 18:51, 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 Alberto,<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">On 25/02/2020 10:43, alberto micol
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" 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>
</blockquote>
<br class="">
<br class="">
I completely agree. But we should also be careful to the existing
implementations. [which leads me to the points below]<br class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<div class="">
<div class="">
<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 class=""><br class="">
</div>
<div class="">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 class="">
<br class="">
PostGIS and the geometries of SQLServer are not yet used by every
databases in the VO, and so is the OGC standard.<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<div class="">
<div class="">
<div class="">(1) the distance between two neighbouring countries, take
Germany and France, is zero,</div>
<div class="">otherwise they would not be neighbouring at all ! <br class="">
</div>
</div>
</div>
</blockquote>
<br class="">
<br class="">
I agree.<br class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<div class="">
<div class="">
<div class="">(2) The definition already exists in the
universally-adopted OGC standard:</div>
<div class=""><i class=""> "the distance between two geometries is
the shortest distance between any two points in those two
geometries"</i></div>
<div class=""> (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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<div class="">
<div class="">
<div class="">
<div class="">
<div class="">(3) Many DBMSes already operationally use such
definition (e.g., PostGIS, SQLServer, ORACLE). <br class="">
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="">
<br class="">
...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 class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<div class="">
<div class="">
<div class="">
<div class="">(4) Adopting any different definition would
only cause confusion to everybody.</div>
</div>
</div>
</div>
</blockquote>
<br class="">
<br class="">
...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 class="">
But yes, I agree, it would be much better to follow an existing
worldwide standard.<br class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<div class="">
<div class="">
<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 class="">
<br class="">
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 class="">
<br class="">
Cheers,<br class="">
Grégory<br class="">
<br class="">
<br class="">
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 class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:5B58489C-7A7C-4D9C-8A9F-B4F01F17D475@googlemail.com" class="">
<div class="">
<div class="">
<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 class="">
</div>
</div></blockquote></div><br class=""></div></body></html>