ADQL XMATCH
François-Xavier Pineau
francois-xavier.pineau at astro.unistra.fr
Wed Feb 10 10:53:35 CET 2016
I agree with Marco and Mark, so just a last comment on this thread.
On 02/09/2016 06:49 PM, Arnold Rots wrote:
> That would be nice, but I suspect that people might find it too
> complicated.
I guess most astronomers are used to the chi-square test so
it should not be that complicated to understand.
We just have to show them how it can be done iteratively
when cross-correlating more than 2 catalogues
(weighted mean positions and associated errors is the answer).
> 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.
Well, although it may not be really clear in my mind,
for me the cross-match is just the selection of candidates
(based on a chi-square test if we account for the positional errors,
fixing a significance level).
Then, computing and putting threshold on Bayesian
probabilities/posterior likelihoods,
performing cuts based on color-color diagrams/... is part of the
cross-identification
and can be made in a second step.
fx
>
> - 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 12:23 PM, François-Xavier Pineau
> <francois-xavier.pineau at astro.unistra.fr
> <mailto: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 <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>
>> 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
>
>
--
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/20160210/bb834c02/attachment-0001.html>
More information about the dal
mailing list