TAP 1.1 comments

Patrick Dowler pdowler.cadc at gmail.com
Mon May 9 10:23:34 CEST 2016


Responding to myself...

Of course, the signatures of CONTAINS and INTERSECTS really should be
specified in ADQL-2.1 and TAP shouldn't be restricting it further. The
reason for that separate "proposed text for TAP-1.1" was just to write
down what TAP needs from ADQL (minimally).

That would be: POINT, CIRCLE, POLYGON (all with no coordsys arg),
CONTAINS, INTERSECTS, CENTROID, COORD1, and COORD2. If we get rid of
the coordsys arg, then the COORDSYS function is unnecessary.

As mentioned in that text, I would like to see REGION dropped as well
because it introduces polymorphism that is highly painful to deal with
(eg in an uploaded table). Of course, services may define UDFs for
other shapes if hey need them now and in future we may add other
shapes to DALI and ADQL.


my 2c,

Pat

On 9 May 2016 at 01:01, 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...
>
>> 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.
>
>> 3) I would really like to add a requirement that TAP/async jobs run
>>    immediately if the parameter PHASE=RUN is passed during the initial
>>    submission.  As I understand it, this was always intended to be
>>    true, but was never specified.  I can work on the text if needed.
>
> If this behaviour is specified in UWS-1.1 then it is the case already.
> If not, then I don't think TAP is the place to do this... we could
> clarify this point, but restating things from other specs usually only
> leads to confusion.
>
>
>
>
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada



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


More information about the dal mailing list