ADQL DISTANCE argument?

[alberto micol]

Dear DAL,

At ESO we use DISTANCE( geometry, geometry ),
where geometry can be a point, a circle, a polygon, a union of polygons, a centroid, etc.

The OGC standard: 
	OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture
	available at: http://portal.opengeospatial.org/files/?artifact_id=25355
	in the paragraph: 6.1.2.4 Methods that support spatial analysis
defines DISTANCE (along with, intersection, unions, etc).

No point in reinventing the wheel: let’s just take that definition and reuse it.
I quote it here:
Distance (anotherGeometry: Geometry):Double — Returns the shortest distance between any two Points in the two geometric objects as calculated in the spatial reference system of this 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. 


Regarding the grammar, something like this would do:

DISTANCE <left_paren> <geometry_value_function> <comma> <geometry_value_function> <right_paren>

where, though, I would ask to modify the current definition of <geometry_value_function>,
which is:
<geometry_value_function> ::=
        <box>
      | <centroid>
      | <circle>
      | <point>
      | <polygon>
      | <user_defined_function>
probably removing the deprecated (is it still?) <box> 
and adding:

	| <union_of_geometries>

with:

<union_of_geometries> ::=
        UNION <coord_sys> <left_paren>
		<geometry_value_function>
		{ <geometry_value_function> } ?
            <right_paren>
Alberto


> On 19. Feb 2020, at 16:14, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Dear DAL,
> 
> Current ADQL says:
> 
>  Functions like AREA, COORD1, COORD2 and DISTANCE accept a
>  geometry and return a calculated numeric value.
> 
>  The specification defines two versions of the DISTANCE function, one
>  that accepts two geometries, and one that accepts four separate numeric
>  values, both forms return a numeric value.
> 
> Both statements would indicate that DISTANCE should accept general
> geometries, i.e., including circles and polygons.  
> 
> The later definition of DISTANCE then says
> 
>  The specification defines two versions of the DISTANCE function,
>  one that accepts two POINT values, and a second that accepts four
>  separate numeric values.
> 
> -- which is clear enough, had it not been for the previous statement,
> and the later statement
> 
>  If the geometric arguments are expressed ...
> 
> which might again be understood as saying the arguments can be more
> general.
> 
> Finally, the grammar says, for the geometry case:
> 
>  DISTANCE <left_paren> <coord_value> <comma> 
>    <coord_value> <right_paren>
> 
> where
> 
>  <coord_value> ::= <point> | <column_reference>
> 
> I *think* all this works out to say that over and above the grammar,
> for distance there's the additional constraint that column_reference
> must be POINT-typed.[1]  
> 
> Being general here is a pain in the neck (actually, that's why I ran
> into this question).  For one, you'll need to define distance
> much more carefully for such geometries, and if (as I think we ought
> to) we chose "minimum of distances of between all points in arg 1 and
> arg 2", I doubt we'll see many correct implementations of that.  Also
> I'll want to map a lot of DISTANCE calls into contains(point,
> circle) statements (because that's much easier on the query planner),
> and that's a pain if one of the points could actually be, say, a
> polygon.
> 
> So... do we agree that DISTANCE only accept POINT-s?
> 
> If so, I'd suggest to just drop the sentence:
> 
>  Functions like AREA, COORD1, COORD2 and DISTANCE accept a
>  geometry and return a calculated numeric value.
> 
> Then change
> 
>  The specification defines two versions of the DISTANCE function,
>  one that accepts two geometries, and one that accepts four
>  separate...
> 
> to
> 
>  This specification defines two versions of the DISTANCE function,
>  one that accepts two POINTs, and one that accepts four
>  separate...
> 
> And then add in 4.2.16 in some appropriate location something like
> 
>  Note that when <column reference>s[2] are passed into DISTANCE, the
>  operation is only defined for POINT-typed values.  Behaviour for
>  other geometries is undefined at this point (but may be defined
>  later).
> 
> Would anyone veto a PR to this effect?  Would anyone prefer something
> completely different?  Would anyone volunteer for doing the PR?
> 
>           -- Markus
> 
> [1] Incidentally, the grammar rules are incompatible with the
> statement in the 4.2.16 that "[t]he DISTANCE function may be applied
> to any expression that returns a geometric POINT value"; I see why it
> was put in, but unless we fix the grammar, we should remove the
> prose.
> 
> [2] or <geometry_value_expression>s, depending on how you think about
> [1]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20200221/d50413b0/attachment-0001.html>