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