ADQL 2.1: Preferred crossmatch syntax

Markus Demleitner msdemlei at
Fri Nov 3 11:26:24 CET 2017


On Thu, Nov 02, 2017 at 12:26:43PM +0000, Mark Taylor wrote:
>    - Is DISTANCE (in 2 flavours) the best syntax to use here?
>      I think it's what we agreed on in Cape Town, partly on the
>      grounds that its meaning is transparent and it doesn't require
>      any new ADQL syntax.  But I don't care that much what the
>      syntax is, as long as it's agreed.  The other possibility
>      that I know has been used (is currently recommended in TOPCAT,
>      but never to my knowledge explicitly endorsed in any standard
>      or Note) is
>      1=CONTAINS(POINT(lon1, lat1), CIRCLE(lon2, lat2, r_max_deg)).
>      But that looks much less user-friendly to me.

I believe you are right on that.  Let's go for DISTANCE.  I'd have
preferred a single flavour of DISTANCE, but we need the
DISTANCE(POINT, POINT) one, while almost none of the actual database
tables have POINTs right now.  Hence, forcing POINTs everywhere would
be an undue burden on the overwhelmingly typical use case.

>    - Is this promotion of a preferred crossmatch form a good idea?
>      I think it is, for the reasons sketched above, but if anybody
>      is unconvinced I can try to argue the case more strongly.

I'm in on it, so for me there's no need to waste your breath.

>    - Does the wording about which point goes in first/second position
>      make sense?  Is it the right way round?  I know that different
>      services prefer different orders (e.g. TAPVizieR vs. DaCHS).
>      Again, I don't care which it is, but if it's the sort of thing
>      that TAP implementations can benefit from (and I have the
>      impression that it is) there should be an agreement.

Here, I think we shouldn't say anything (i.e., just drop the entire
paragraph).  These troubles are essentially an ugly implementation
detail that hopefully will go away as libraries and planners improve
(after all, it's the planner's job to exploit symmetries in a
database system).  We shouldn't burden a spec text with this.

        -- Markus

More information about the dal mailing list