ADQL DISTANCE argument?

[alberto micol]

Dear Gregory,

I fully commend your will to finish ADQL-2.1 asap.
Still, one should be careful in defining things in a way that does not block developers, providers, use cases, and user’s uptake.

> On 24. Feb 2020, at 11:20, Gregory MANTELET <gregory.mantelet at astro.unistra.fr> wrote:
> 
> Dear DAL,
> 
> 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).

I do not see the need for any debate, as the world is already using one and only one definition:

(1) the distance between two neighbouring countries, take Germany and France, is zero,
otherwise they would not be neighbouring at all ! 

(2) The definition already exists in the universally-adopted OGC standard:
     "the distance between two geometries is the shortest distance between any two points in those two geometries"
    (see: OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture
	available at: http://portal.opengeospatial.org/files/?artifact_id=25355 <http://portal.opengeospatial.org/files/?artifact_id=25355> )

(3) Many DBMSes already operationally use such definition (e.g., PostGIS, SQLServer, ORACLE). 

(4) Adopting any different definition would only cause confusion to everybody.

(5) Adopting existing standards can only speed up our VO work.

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).

With the above definition, and with the grammar that I already proposed in an earlier email,
we are ready to proceed with no further delays to the publication of the ADQL2.1.

Regarding centroids, yes, I’m in!

Many thanks,
Alberto

> 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(...)) ).
> 
> 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.
> 
> To sum up my thoughts:
> 
> (for more readability here, I did not replace the parenthesis and comma with their BNF equivalent)
> ---------------------------------------------------------------------
> <distance> ::=
>     DISTANCE(<coord_value>, <coord_value>)
>   | DISTANCE(<numeric_value_expression>, <numeric_value_expression>,
>              <numeric_value_expression>, <numeric_value_expression>)
> 
> <coord_value> ::= <point_value> | <column_reference>
> 
> <point_value> ::= <point> | <centroid>
> ---------------------------------------------------------------------
> 
> 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.
> 
> I can start a GitHub's PR with these and the suggestions of Markus, if you want to.
> 
> Cheers,
> Grégory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20200225/99aa0d4d/attachment.html>