<div dir="ltr"><div><div><div><div><div>Alowing the two radii to be specified separately would make it more<br></div>explicit that they are associated with specific catalogs and allows<br></div>users to keep track of those specific catalog-dependent values, particularly<br></div>if they do cross-matching involving multiple catalogs.<br><br></div>One might even consider returning the overlap ratio (area of intersection<br>over area of smallest circle) as a (admittedly somewhat bogus) match probability .<br><br></div><div>Cheers,<br><br></div><div>  - Arnold<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots                                          Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory                   tel:  +1 617 496 7701<br>60 Garden Street, MS 67                                      fax:  +1 617 495 7356<br>Cambridge, MA 02138                                         <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA                                                   <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 9, 2016 at 11:50 AM, Tom McGlynn (NASA/GSFC Code 660.1) <span dir="ltr">&lt;<a href="mailto:tom.mcglynn@nasa.gov" target="_blank">tom.mcglynn@nasa.gov</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Arnold,<br>
<br>
Assuming you mean for a match to occur whenever the two circles overlap, then wouldn&#39;t<br>
<br>
    xmatch(ra1,dec1,rad1, ra2,dec2,rad2)<br>
<br>
be equivalent to<br>
<br>
   xmatch(ra1, dec1, ra2, dec2, rad1+rad2)<br>
<br>
if we&#39;re returning only integer values 1 and 0.<br>
<br>
I suppose one could define this differently with<br>
   xmatch(ra1,dec1,rad1, ra2, dec2,rad2)<br>
returning the fraction of the circle defined by ra1,dec1,rad1 which<br>
is enclosed in the second circle.  Not sure I really see the use case for that though.<br>
<br>
    Tom<br>
<br>
<br>
Arnold Rots wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I don&#39;t think I am the only one who is not enamored of these<br>
brute-force unnuanced cross-matches, but I wonder whether<br>
it would be helpful to improve them by allowing two radii.<br>
<br>
Cheers,<br>
<br>
  - Arnold<br>
<br>
-------------------------------------------------------------------------------------------------------------<br>
Arnold H. Rots Chandra X-ray Science Center<br>
Smithsonian Astrophysical Observatory tel:  <a href="tel:%2B1%20617%20496%207701" value="+16174967701" target="_blank">+1 617 496 7701</a><br>
60 Garden Street, MS 67   fax:  <a href="tel:%2B1%20617%20495%207356" value="+16174957356" target="_blank">+1 617 495 7356</a><br></span>
Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a> &lt;mailto:<a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a>&gt;<br>
USA <a href="http://hea-www.harvard.edu/~arots/" rel="noreferrer" target="_blank">http://hea-www.harvard.edu/~arots/</a> &lt;<a href="http://hea-www.harvard.edu/%7Earots/" rel="noreferrer" target="_blank">http://hea-www.harvard.edu/%7Earots/</a>&gt;<br>
--------------------------------------------------------------------------------------------------------------<div><div class="h5"><br>
<br>
<br>
On Tue, Feb 9, 2016 at 10:21 AM, Mark Taylor &lt;<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a> &lt;mailto:<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>&gt;&gt; wrote:<br>
<br>
    Hi Marco and DAL,<br>
<br>
    I support the introduction of a new XMATCH function for two main<br>
    reaons:<br>
<br>
    Usability:<br>
       A dedicated crossmatch function should be easier<br>
       for users to use and remember, and all round less horrible,<br>
       than the current recommended(?) cross-match idiom:<br>
          1 = CONTAINS(POINT(coordsys, lon1, lat1),<br>
                       CIRCLE(coordsys, lon2, lat2, radius))<br>
       (where coordsys is a string that should probably be &#39;ICRS&#39;, or<br>
       maybe should be empty, but anyway is unlikely to make much<br>
       difference to the result).<br>
<br>
    Implementability:<br>
       It may make it easy/possible to provide standard ADQL syntax for<br>
       efficient sky crossmatching in database backends that otherwise<br>
       can&#39;t do it, because they have trouble implementing the ADQL<br>
       geometry functions (because they lack pgSphere).<br>
<br>
    In my opinion it should look like this:<br>
<br>
        1 = XMATCH(lon1, lat1, lon2, lat2, radius)<br>
<br>
    The alternative would presumably be<br>
<br>
        1 = XMATCH(POINT(coordsys, lon1, lat1), POINT(coordsys, lon2,<br>
    lat2), radius)<br>
<br>
    which from the point of view of usability is not much better than<br>
    the status quo.  Although I believe the annoying and disingenuous<br>
    coordsys argument to the geometry functions is scheduled for removal<br>
    from ADQL, my understanding is that it&#39;s not intended for this<br>
    (minor) revision.  Even without the coordsys arg, I think the<br>
    POINTless form looks less intimidating for users.<br>
<br>
    I would have thought that from the point of view of implementability<br>
    as well the POINTless form presents fewer constraints.<br>
    However, I&#39;m not a database implementation person, so I might be<br>
    wrong about that.<br>
<br>
    Mark<br>
<br>
    On Tue, 9 Feb 2016, Marco Molinaro wrote:<br>
<br>
    &gt; Dear DAL members and ADQL fans,<br>
    &gt; to go on with the ADQL-2.1 working draft<br>
    &gt; one issue is left, from Sydney interop,<br>
    &gt; to be discussed.<br>
    &gt;<br>
    &gt; In the DAL splinter at the interop<br>
    &gt; it was agreed to add an XMATCH function<br>
    &gt; of binary type and definition<br>
    &gt;<br>
    &gt; 1 = XMATCH(a,b,radius)<br>
    &gt;<br>
    &gt; However no agreement was reached about<br>
    &gt; the &#39;a&#39; and &#39;b&#39; parameters, whether they<br>
    &gt; should be points (ADQL:POINT) or RA&amp;Dec<br>
    &gt; couples (floating point values).<br>
    &gt;<br>
    &gt; Both choices have advantages and disadvantages.<br>
    &gt; Points are more into the logic<br>
    &gt; of a sky cross-match but require geometric<br>
    &gt; types to be directly available to the DB.<br>
    &gt; Coordinates couples are directly available<br>
    &gt; in whatever DB and would also let the XMATCH<br>
    &gt; function work for non-orthodox coordinates<br>
    &gt; matching, but of course loosing the sky matching<br>
    &gt; logic.<br>
    &gt;<br>
    &gt; As I said (also due to time constraints) no<br>
    &gt; agreement was found in Sydney.<br>
    &gt;<br>
    &gt; What&#39;s your opinion on this, and why?<br>
    &gt;<br>
    &gt; Cheers,<br>
    &gt;     Marco<br>
    &gt;<br>
<br>
    --<br>
    Mark Taylor   Astronomical Programmer   Physics, Bristol<br>
    University, UK<br></div></div>
    <a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> &lt;mailto:<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a>&gt;<br>
    <a href="tel:%2B44-117-9288776" value="+441179288776" target="_blank">+44-117-9288776</a> &lt;tel:%2B44-117-9288776&gt;<br>
    <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a> &lt;<a href="http://www.star.bris.ac.uk/%7Embt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/%7Embt/</a>&gt;<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>