ADQL XMATCH

[Mark Taylor]

Hi Marco and DAL,

I support the introduction of a new XMATCH function for two main reaons:

Usability:
   A dedicated crossmatch function should be easier
   for users to use and remember, and all round less horrible,
   than the current recommended(?) cross-match idiom:
      1 = CONTAINS(POINT(coordsys, lon1, lat1),
                   CIRCLE(coordsys, lon2, lat2, radius))
   (where coordsys is a string that should probably be 'ICRS', or
   maybe should be empty, but anyway is unlikely to make much
   difference to the result).

Implementability:
   It may make it easy/possible to provide standard ADQL syntax for
   efficient sky crossmatching in database backends that otherwise
   can't do it, because they have trouble implementing the ADQL
   geometry functions (because they lack pgSphere).

In my opinion it should look like this:

    1 = XMATCH(lon1, lat1, lon2, lat2, radius)

The alternative would presumably be

    1 = XMATCH(POINT(coordsys, lon1, lat1), POINT(coordsys, lon2, lat2), radius)

which from the point of view of usability is not much better than
the status quo.  Although I believe the annoying and disingenuous
coordsys argument to the geometry functions is scheduled for removal
from ADQL, my understanding is that it's not intended for this
(minor) revision.  Even without the coordsys arg, I think the
POINTless form looks less intimidating for users.

I would have thought that from the point of view of implementability
as well the POINTless form presents fewer constraints.
However, I'm not a database implementation person, so I might be
wrong about that.

Mark

On Tue, 9 Feb 2016, Marco Molinaro wrote:

> Dear DAL members and ADQL fans,
> to go on with the ADQL-2.1 working draft
> one issue is left, from Sydney interop,
> to be discussed.
> 
> In the DAL splinter at the interop
> it was agreed to add an XMATCH function
> of binary type and definition
> 
> 1 = XMATCH(a,b,radius)
> 
> However no agreement was reached about
> the 'a' and 'b' parameters, whether they
> should be points (ADQL:POINT) or RA&Dec
> couples (floating point values).
> 
> Both choices have advantages and disadvantages.
> Points are more into the logic
> of a sky cross-match but require geometric
> types to be directly available to the DB.
> Coordinates couples are directly available
> in whatever DB and would also let the XMATCH
> function work for non-orthodox coordinates
> matching, but of course loosing the sky matching
> logic.
> 
> As I said (also due to time constraints) no
> agreement was found in Sydney.
> 
> What's your opinion on this, and why?
> 
> Cheers,
>     Marco
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/