TAP 1.1 comments

[Markus Demleitner]

Hi,

On Mon, May 09, 2016 at 03:34:11AM -0700, Walter Landry wrote:
> Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> > comments below
> > 
> > On 8 May 2016 at 16:55, Walter Landry <wlandry at caltech.edu> wrote:
> >> Hi Everyone,
> >>
> >> Here are some comments on the TAP 1.1 proposal.
> >>
> >> 1) The text proposes
> >>
> >>      INTERSECTS and CONTAINS are required. POINT, CIRCLE, and POLYGON
> >>      are required. POINT (and point-valued columns) cannot be used as
> >>      an argument to INTERSECTS.
> >>
> >>    What is the rationale for not allowing POINT's in INTERSECTS?
> > 
> > It is redundant with CONTAINS and iirc some people found INTERSECTS
> > decaying to CONTAINS a pain to implement...
> 
> Ok.  That is surprising to me.  We already need to have cases for
> 
>   (circle,circle)
>   (circle,polygon)
>   (polygon,circle)
>   (polygon,polygon)
> 
> So it would just be adding a few more cases.
> 
>   (point,point)
>   (point,circle)
>   (circle,point)
>   (point,polygon)
>   (polygon,point)

I'm always for "as few special cases as possible", so more than
doubling the number of special cases without adding functionality to
the language does not seem a terribly good deal to me.  And of
course, given we're talking about floating point coordinates, I'd
like to scare away people from (point, point) arguments to geometric
functions anyway.

My take: CONTAINS isn't that bad.  And there's enough implementors
got (and will still get) wrong with geometries in ADQL anyway.

> >> 2) The text says
> >>
> >>      A query with MAXREC=0 can be used with a simple query
> >>      (e.g. SELECT * FROM some_table) to extract and examine the
> >>      VOTable metadata (assuming FORMAT=votable). Note: in this version
> >>      of TAP, this is the only mechanism to learn some of the detailed
> >>      metadata, such as coordinate systems used.
> >>
> >>    I thought that TAP_SCHEMA.columns has all of that metadata?
> > 
> > There is no coordinate system metadata in the tap_schema.
> 
> Can we add it?

This has been discussed at some length during TAP 1.0 specification,
and the conclusion back then was that STC metadata (glon, glat are
Galactic positions for epoch 2014.5302 (BDT), with reference position
at the solar system barycenter, with errors in glon_err, glat_err;
there's their temporal derivatives in...) is too complex to be
representable in relational form without doubling the size of
TAP_SCHEMA.

And anyway, I'd be extremely happy if we finally could represent STC
metadata in VOTable in a way that a sufficient number of toosl
actually understand...

Cheers,

         Markus