TAP 1.1 comment on INTERSECTS and point-valued columns

[alberto micol]

Dear DAL,

I need to come back to this one issue of the missing INTERSECTS support for point-valued columns.
I quote here the relevant ADQL2.1 text:
> The arguments to INTERSECTS SHOULD be geometric expressions evaluating to either BOX, CIRCLE, 
> POLYGON, or REGION. Previous versions of this specification allow POINTs as well and require servers 
> to interpret the expression as a CONTAINS with the POINT moved into the first position. Servers 
> SHOULD still implement that behaviour, but clients SHOULD NOT expect it. This behaviour will be 
> dropped in the next major version of this specification. 

Here is my simple and useful ObsCore use case:
   Find *all* ESO products whose footprints (s_region) intersects a given region.

Some of the ESO products have an s_region expressed as a polygon (e.g. images),
some other products (e.g. all the ESO spectra) have an s_region that is a point.
 
Do I understand correctly that a user executing this ADQL:

   select * from ivoa.ObsCore where INTERSECTS( s_region, circle(‘’,83.867,-69.276,1)=1) 

should not expect to see returned any record with a point-valued s_region,
that is, none of the ESO spectra?

If that is true:

how will a user know that such a query might not return products like the ESO spectra or visibilities?

and why should a user instead type the following ADQL to ensure that ALL products are returned?
SELECT * from ivoa.ObsCore where 
(   INTERSECTS(s_region,CIRCLE('ICRS',83.867,-69.276, 0.1)) = 1 )
or
( CONTAINS(s_region,CIRCLE('ICRS',83.867,-69.276, 0.1)) = 1 )


Should we change the ESO implementation and return, for spectra and visibilities,
a CIRCLE with a zero radius instead of a point?

Many thanks,
Alberto

  
 
> On 10 May 2016, at 10:00, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> 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.
> 

> On 09 May 2016, at 10:01, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> On 8 May 2016 at 16:55, Walter Landry <wlandry at caltech.edu <mailto: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...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170821/6f341f84/attachment.html>