ADQL XMATCH

Tue Feb 9 18:49:17 CET 2016

That would be nice, but I suspect that people might find it too complicated.
Besides, the you really would want to do a proper Bayesian cross-match
that handles complete collections of sources and takes into account the
areas of coverage as well.

  - 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
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------

On Tue, Feb 9, 2016 at 12:23 PM, François-Xavier Pineau <
francois-xavier.pineau at astro.unistra.fr> wrote:

> 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
> USA
> <http://hea-www.harvard.edu/%7Earots/>http://hea-www.harvard.edu/~arots/
>
> --------------------------------------------------------------------------------------------------------------
>
>
> On Tue, Feb 9, 2016 at 11:50 AM, Tom McGlynn (NASA/GSFC Code 660.1) <
> <tom.mcglynn at nasa.gov>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
>>> 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>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/
>>> >
>>>
>>>
>>>
>>
>
>
> --
> 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/3b4cbe23/attachment-0001.html>