ADQL XMATCH

[Mark Taylor]

What two radii do you have in mind?

If you like nuances, there are plenty available - you can use the
existing CONTAINS function with the various region types defined in ADQL.
Nobody is suggesting that those be retired or outlawed, but I would
like to see the proposed XMATCH syntax available for the 90%(?) of
cases when a simple isotropic distance criterion is what's wanted.

On Tue, 9 Feb 2016, Arnold Rots wrote:

> I don't think I am the only one who is not enamored of these
> brute-force unnuanced cross-matches, but I wonder whether
> it would be helpful to improve them by allowing two radii.
> 
> Cheers,
> 
>   - Arnold
> 
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 496
> 7701
> 60 Garden Street, MS 67                                      fax:  +1 617
> 495 7356
> Cambridge, MA 02138
> arots at cfa.harvard.edu
> USA
> http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------------------------------------------
> 
> 
> On Tue, Feb 9, 2016 at 10:21 AM, Mark Taylor <M.B.Taylor at bristol.ac.uk>
> wrote:
> 
> > 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/
> >
> 

--
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/