ADQL XMATCH

[Arnold Rots]

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


On Tue, Feb 9, 2016 at 10:21 AM, Mark Taylor <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 +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160209/6dae5bbb/attachment-0001.html>