ADQL XMATCH
Arnold Rots
arots at cfa.harvard.edu
Tue Feb 9 18:01:54 CET 2016
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/~arots/
--------------------------------------------------------------------------------------------------------------
On Tue, Feb 9, 2016 at 11:50 AM, Tom McGlynn (NASA/GSFC Code 660.1) <
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
>> <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/>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160209/a4735933/attachment-0001.html>
More information about the dal
mailing list