ADQL XMATCH

[Tom McGlynn (NASA/GSFC Code 660.1)]

Arnold,

Assuming you mean for a match to occur whenever the two circles overlap, 
then wouldn't

     xmatch(ra1,dec1,rad1, ra2,dec2,rad2)

be equivalent to

    xmatch(ra1, dec1, ra2, dec2, rad1+rad2)

if we're returning only integer values 1 and 0.

I suppose one could define this differently with
    xmatch(ra1,dec1,rad1, ra2, dec2,rad2)
returning the fraction of the circle defined by ra1,dec1,rad1 which
is enclosed in the second circle.  Not sure I really see the use case 
for that though.

     Tom


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 <mailto:arots at cfa.harvard.edu>
> USA http://hea-www.harvard.edu/~arots/ 
> <http://hea-www.harvard.edu/%7Earots/>
> --------------------------------------------------------------------------------------------------------------
>
>
> On Tue, Feb 9, 2016 at 10:21 AM, Mark Taylor <M.B.Taylor at bristol.ac.uk 
> <mailto: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 <mailto:m.b.taylor at bris.ac.uk>
>     +44-117-9288776 <tel:%2B44-117-9288776>
>     http://www.star.bris.ac.uk/~mbt/ <http://www.star.bris.ac.uk/%7Embt/>
>
>