ADQL XMATCH

François-Xavier Pineau francois-xavier.pineau at astro.unistra.fr
Tue Feb 9 18:23:48 CET 2016


Going this way, why not taking into account elliptical errors:

xmatch(ra1, dec1, a1, b2, pa1, ra2, dec2, a2, b2, pa2, thresold on the 
Mahalanobis distance)

with:
- a: semi major axis
- b: semi minor axis
- pa: position angle

returning the Mahalanobis distance, the weighted mean position and the 
associated elliptical error to be able to coherently chain cross-matches...

Cheers,

fx

On 02/09/2016 06:01 PM, Arnold Rots wrote:
> Alowing the two radii to be specified separately would make it more
> explicit that they are associated with specific catalogs and allows
> users to keep track of those specific catalog-dependent values, 
> particularly
> if they do cross-matching involving multiple catalogs.
>
> One might even consider returning the overlap ratio (area of intersection
> over area of smallest circle) as a (admittedly somewhat bogus) match 
> probability .
>
> 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 11:50 AM, Tom McGlynn (NASA/GSFC Code 660.1) 
> <tom.mcglynn at nasa.gov <mailto:tom.mcglynn at nasa.gov>> wrote:
>
>     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
>         <tel:%2B1%20617%20496%207701>
>         60 Garden Street, MS 67   fax: +1 617 495 7356
>         <tel:%2B1%20617%20495%207356>
>         Cambridge, MA 02138 arots at cfa.harvard.edu
>         <mailto:arots at cfa.harvard.edu> <mailto:arots at cfa.harvard.edu
>         <mailto:arots at cfa.harvard.edu>>
>         USA http://hea-www.harvard.edu/~arots/
>         <http://hea-www.harvard.edu/%7Earots/>
>         <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>
>         <mailto: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>
>         <mailto:m.b.taylor at bris.ac.uk <mailto:m.b.taylor at bris.ac.uk>>
>         +44-117-9288776 <tel:%2B44-117-9288776> <tel:%2B44-117-9288776>
>         http://www.star.bris.ac.uk/~mbt/
>         <http://www.star.bris.ac.uk/%7Embt/>
>         <http://www.star.bris.ac.uk/%7Embt/>
>
>
>
>


-- 
François-Xavier Pineau
CDS, Observatoire Astronomique de Strasbourg
11, rue de l'Université
F - 67000 Strasbourg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160209/6481ba7b/attachment.html>


More information about the dal mailing list