ADQL XMATCH

[Jesus Salgado]

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.