ADQL XMATCH

[Patrick Dowler]

My impression is that DISTANCE (clear and simple xmatch) is generally
needed for catalogues and not ObsCore, so I'm not too worried about
that. ObsCore does have a point-valued CENTROID(s_region) though :-)



On 11 April 2016 at 16:02, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
> 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/



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada