ADQL XMATCH

[Walter Landry]

Marco Molinaro <molinaro at oats.inaf.it> wrote:
> 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.

Using points does not require geometric types to be available in the
DB.  Our TAP service does not have types.  We rewrite the query to use
the appropriate columns under the hood.

I strongly prefer using real types over coordinates.  It makes it
easier to analyze the query and rewrite it into something our multiple
back ends can handle.  Arbitrary columns are easier only if you have
geometry support baked into the DB.

As for Mark Taylor's comment about POINT being obtuse, I would prefer
to solve that problem by introducing a POINT literal.  As an example,
we could set

  {a,b} -> POINT('ICRS GEOCENTER',a,b)

Then the XMATCH example would be something like

  XMATCH(db_table.pos, {my_table.ra, my_table.dec}, my_table.radius)

We could also use [] if you do not like {}.

Cheers,
Walter Landry