ADQL XMATCH

[Marco Molinaro]

Dear all,
let me: summarize, refresh and propose a way to go on with the
crossmatch functionality in ADQL, in view of the oncoming Cape Town
Interop.
(warning: summary will be really sketchy, don't take offence if I let
out your specific point)

We started out of 1=XMATCH(a,b,radius) and the duality a,b: point or
coord couple?
This was to avoid the 1=CONTAINS(...) existing solution.
However, simple arguments showed it not to be probably a good solution, e.g.
- it's fixed to have a 1/0 response to mimic boolean
- it's a brute force solution to a complex matching scenario
- function name not that brilliant considering this last concern
However, to have a simple distance estimator available quickly in
ADQL, we cannot work on more complex solutions in v2.1 (it's a minor),
so a proposal was to bend towards a DISTANCE(ra1,dec1,ra2,dec2) <
radius solution.
Apart from skipping the complex scenario cross match, this one _only_
the drawback that we need to understand how to work or work-around the
overload in ADQL since DISTANCE(<POINT>,<POINT>) already exists.
(and maybe clearly define whether we need to keep only this one, not
to skip epoch issues).
A suggestion was also to have someone write a Note on the way to write
performant sky positional crossmatches in ADQL.

Now, if we'd like to have an ADQL WD ready for Cape Town, we have two ways:
- finalize discussion here and put the outcome in the WD
- put an RFC outcome in the WD anyway and finalize it in Cape Town

In both cases there will be a TAP/ADQL session at the Interop where
contributions will be highly welcome on this, other ADQL related open
issues and future ADQL developments (and here I am referring
explicitly to the proposed way of having crossmatch with estimators or
other solutions to the xmatch problem).

Please don't stop providing your contribution here, because it's
contribution that makes VO go on.
And don't forget to submit your contribution to Cape Town Interop DAL
session (now, of after the call comes to your inbox).

Cheers,
    Marco


2016-02-15 19:00 GMT+01:00 Jesus Salgado <Jesus.Salgado at sciops.esa.int>:
> Hi all,
>
> Just a couple of comments on this from my side.
>
> - We should _not_ use ra,dec pairs like in
>
> DISTANCE(ra1,dec1,ra2,dec2)<radius
>
> for a correct crossmatch. We should not ignore epochs and the possible
> need of using proper motions. Classical catalogues are in J2000, Gaia
> will be in J2015 and future Euclid catalogue probably in J2022 or
> similar. So it should be at least:
>
> DISTANCE(<POINT>, <POINT>)< distance
>
> Doing that, we provide support to services that correctly allow
> coordinates propagation and, on the other hand, people can write the
> points themselves with ra, dec  or even using a column of type POINT in
> case of not support for coordinates propagation.
>
> But....................
>
> - We should need to standardize the way to define ESTIMATORS. This is
> why it is better not to use ADQL DISTANCE but something more specific
> that allows the inclusion of estimators (in the line proposed by Juan
> Gonzalez and Laszlo). This is in my view the issue to be discussed.
>
>
> Cheers,
> Jesus
>
> On Thu, 2016-02-11 at 10:34 +0100, Marco Molinaro wrote:
>> Hi all,
>> thanks, Mark, for pointing out the summary slide you presented in
>> Sydney.
>> Again, it gives a good view of what we're looking for at this stage
>> (please, don't get annoyed with me if I bounce back again to the -
>> minimal? - topic).
>> I do like Laurent's suggestions and agree with Grégory's view.
>>
>>
>> Am I right if I say that we're converging towards a
>> - XMATCH seems not a good name
>> - we have to work out what we can do with DISTANCE given it already
>> exists in the 2.0 version of the REC
>> - point vs ra/dec should both work but overload as to be nicely
>> specified (again, requires changes wrt 2.0)
>> - binary versus float function type
>> ?
>>
>>
>> [my opinion is that we cannot touch what DISTANCE in ADQL already is,
>> but we may experiment the overload solution defining it in the
>> document]
>>
>>
>> Not to a solution yet, but at least defining the goal?
>> And this was for the 2.1 (minor) revision.
>>
>>
>>
>> Afterwards we have to better cope with the real intent of a cross
>> match, not only with the "cheap" solution to smooth what is probably
>> in-between and errata and a feature change in the current
>> specification.
>>
>>
>> May I ask if a specific session/sub-session on this may be of interest
>> in Cape Town? (if you plan to participate)
>>
>>
>> Cheers,
>>     Marco
>
> --
> Jesus J. SALGADO
> ESAC Science Data Centre
> Science Archives and Computer Engineering Unit
> Operations Department, Directorate of Science
> European Space Astronomy Centre (ESAC)
> ISDEFE for European Space Agency (ESA)
>
> ESAC, European Space Astronomy Centre
> P.O. Box 78
> E-28691 Villanueva de la Cañada, Madrid, Spain
> Jesus.Salgado at sciops.esa.int | www.esa.int
> Tel. +34 918 131 271         | Fax  +34 918 131 218
>
>
> This message and any attachments are intended for the use of the addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the sender.
>
> Please consider the environment before printing this email.
>