ADQL XMATCH

[Mark Taylor]

On Mon, 11 Apr 2016, Mark Taylor wrote:

> The main reason I'm uncomfortable with the 2-arg form (which I agree
> is cleaner - it's how I'd want to see it in a java API for instance)
> is that provision of POINT datatypes in TAP services is still
> a minority pastime.  I count (using GLOTS) only three services
> providing at least one table with POINT or adql:POINT column:
> CADC, GAVO-DC and SimTAP.  There are also a number of JVO
> services with the non-standard type "jpoint", I presume doing
> something similar.  The other 80-odd registered TAP services
> out there get by representing sky positions with RA and Dec columns.
> So queries to most services are going to be more verbose
> (requiring DISTANCE(POINT(ra1,dec1), POINT(ra2,dec2))
> rather than DISTANCE(ra1,dec1,ra2,dec2)) so that queries to
> a few services can be shorter (DISTANCE(pos1,pos2), or
> often DISTANCE(pos,POINT(upload.ra,upload.dec))).

PS I've just noticed that ObsCore 1.1 specifies no POINT-valued columns.
That means that if a TAP service wants to field generic 
ObsCore-defined queries it can't expect those queries to make 
use of POINT-typed columns, even if such columns are provided.
So an ObsTAP service will either have to recognise POINT(s_ra,s_dec) 
as a POINT, or resign itself to non-indexed geometry for ObsTAP queries.

--
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/