<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Going this way, why not taking into
      account elliptical errors:<br>
      <br>
      xmatch(ra1, dec1, a1, b2, pa1, ra2, dec2, a2, b2, pa2, thresold on
      the Mahalanobis distance)<br>
      <br>
      with:<br>
      - a: semi major axis<br>
      - b: semi minor axis<br>
      - pa: position angle<br>
      <br>
      returning the Mahalanobis distance, the weighted mean position and
      the associated elliptical error to be able to coherently chain
      cross-matches...<br>
      <br>
      Cheers,<br>
      <br>
      fx<br>
      <br>
      On 02/09/2016 06:01 PM, Arnold Rots wrote:<br>
    </div>
    <blockquote
cite="mid:CAJXToE_1QkG+65UpKq+QHTz3pTGr7bpxvANs_woov4M0RBbj8A@mail.gmail.com"
      type="cite">
      <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 moz-do-not-send="true"
                href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>
              USA                                                   <a
                moz-do-not-send="true"
                href="http://hea-www.harvard.edu/%7Earots/"
                target="_blank"><a class="moz-txt-link-freetext" href="http://hea-www.harvard.edu/~arots/">http://hea-www.harvard.edu/~arots/</a></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
              moz-do-not-send="true" href="mailto:tom.mcglynn@nasa.gov"
              target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:tom.mcglynn@nasa.gov">tom.mcglynn@nasa.gov</a></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'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'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'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
                  moz-do-not-send="true"
                  href="tel:%2B1%20617%20496%207701"
                  value="+16174967701" target="_blank">+1 617 496 7701</a><br>
                60 Garden Street, MS 67   fax:  <a
                  moz-do-not-send="true"
                  href="tel:%2B1%20617%20495%207356"
                  value="+16174957356" target="_blank">+1 617 495 7356</a><br>
              </span>
              Cambridge, MA 02138 <a moz-do-not-send="true"
                href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a>
              &lt;mailto:<a moz-do-not-send="true"
                href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a>&gt;<br>
              USA <a moz-do-not-send="true"
                href="http://hea-www.harvard.edu/%7Earots/"
                rel="noreferrer" target="_blank">http://hea-www.harvard.edu/~arots/</a>
              &lt;<a moz-do-not-send="true"
                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
                    moz-do-not-send="true"
                    href="mailto:M.B.Taylor@bristol.ac.uk"
                    target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:M.B.Taylor@bristol.ac.uk">M.B.Taylor@bristol.ac.uk</a></a>
                  &lt;mailto:<a moz-do-not-send="true"
                    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 'ICRS', 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'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'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'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 'a' and 'b' 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'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 moz-do-not-send="true"
                href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a>
              &lt;mailto:<a moz-do-not-send="true"
                href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a>&gt;<br>
                  <a moz-do-not-send="true"
                href="tel:%2B44-117-9288776" value="+441179288776"
                target="_blank">+44-117-9288776</a>
              &lt;tel:%2B44-117-9288776&gt;<br>
                  <a moz-do-not-send="true"
                href="http://www.star.bris.ac.uk/%7Embt/"
                rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a>
              &lt;<a moz-do-not-send="true"
                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>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
François-Xavier Pineau
CDS, Observatoire Astronomique de Strasbourg
11, rue de l'Université
F - 67000 Strasbourg</pre>
  </body>
</html>