ADQL XMATCH
Laurent Michel
laurent.michel at astro.unistra.fr
Wed Feb 10 10:06:09 CET 2016
Hi,
I think it is better to have one basic function specifically dedicated to Xmatches based on simple distances.
Most of the users are likely happy with this simple functionality, so let's keep the syntax simple and unambiguous.
In my opinion, more advanced algorithms must be operated by specific but optional functions to prevent implementer from having
to implement algorithms which are out of he scope of most of the TAP services or which could require costly optimisations.
Cheers
LM
Le 09/02/2016 18:23, François-Xavier Pineau a écrit :
> 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/%7Earots/>http://hea-www.harvard.edu/~arots/
>> --------------------------------------------------------------------------------------------------------------
>>
>>
>> On Tue, Feb 9, 2016 at 11:50 AM, Tom McGlynn (NASA/GSFC Code 660.1) <<mailto: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 <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 <<mailto:M.B.Taylor at bristol.ac.uk>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
>
--
jesuischarlie
Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34
More information about the dal
mailing list