TAP 1.1 comment on INTERSECTS and point-valued columns

[alberto micol]

Hi Markus,

I understand you already implemented spectral footprints with a very tiny CIRCLE:
that solves your own issue with your own database when doing smth like:
INTERSECTS( s_region, POLYGON(…) )
or even 
INTERSECTS( ObsCore1.s_region, ObsCore2.s_region)

Then, the only remaining problem you have is to support something like:
INTERSECTS( s_region, POINT(...) )
In that case then use the same trick: make your ADQL translator
change the POINT into a small CIRCLE (e.g. radius 1E-7), and you are done.
Similarly with CENTROID.

Notice please all the “your”s and “you”s in the sentences above...

Luckily, in my case we are using a database that supports all that functionality.
No need to implement all those tricks…
In my case, everything is of datatype “geography”, yes, even the demonised POINTs.

This difference between “your” case and “my” case
shows quite well why a standard should abstain from any implementation
details… let’s leave the implementation details to the implementors!

Given the above, I think it is no problem to remove that confusing and
platform-dependent text from the standards (both ADQL and TAP). Dave? Pat?

Alberto



> On 07 Sep 2017, at 11:51, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Dear DAL,
> 
> TL;DR: As the person who brought up the proposition to drop the
> type-based decay of INTERSECTS to CONTAINS, I formally retract that
> proposition.  While I still think it's technically right (point made
> below), it's not enough of a issue to warrant more optional features.
> 
> On Wed, Sep 06, 2017 at 04:12:41PM +0100, Dave Morris wrote:
>> So the text for INTERSECTS becomes :
>> 
>>    "The arguments to INTERSECTS SHOULD be geometric expressions evaluating
>>     to either BOX, CIRCLE or POLYGON."
>> 
>>    "If a service supports the additional INTERSECTS-POINT feature, then
>>     the arguments to INTERSECTS MAY also include POINT."
>> 
>>    "If a service does not support the INTERSECTS-POINT feature, then
>>     the service MAY return an error when processing INTERSECTS with
>>     a POINT argument"
> 
> Again, my dislike of optional features that clients and users need to
> know about to predict the behaviour of a service overrides all other
> concerns.  Let's not have that and keep it like it is now: *If* you
> implement INTERSECTS, it has to decay, period.  If you don't want to
> do type inference, then don't implement INTERSECTS.
> 
> Having said that, I cannot resist pointing out that...
> 
>> On 2017-09-06 14:58, alberto micol wrote:
>>> Requiring, as stated in ADQL2.1, to interpret INTERSECTS as a CONTAINS
>>> might be a valid suggestion for implementing the standard on a
>>> specific technology, but the standard should not care of how
>>> developers will implement that.
>>> 
>>> Dropping INTERSECTS support for POINTs just because pgsphere cannot
>>> cope well with it
>>> is not the right way to go, other databases cope fine with that.
> 
> ...INTERSECTION with a point is a concept that needs explanation,
> at the very least; just because some implementation gloss over the
> oddity of the operation.  
> 
> I've not read up on how people doing computational geometry (or
> whatever) define intersection.  If you model them as set operations
> (which is at least sensible), however, the situation is clear: CIRCLE
> and POLYGON are *sets* of points, and a POINT is, well, a point.
> Doing a set operation with a point as one operand is clearly
> undefined as such.
> 
> Now, you *can*, if you insist for practical reasons, define
> polymorphous operators.  For CONTAINS, that's at least
> straightforwardly defined.  There, it's is-subset-of for a set-valued
> first operand, and is-element-of for a point-valued first operand.
> For INTERSECTS, that's a lot more involved, as it in effect requires
> mutating one operand (from point to set-of-points).
> 
> Hence, ADQL 2.0 chose to define INTERSECTS in terms of CONTAINS.  I
> stand by my assessment that that's the only place in ADQL in which
> you need to do type inference to define the operation (where I'll
> admit that CONTAINS is a border case).  It is that irreguarity that
> bugged me, regardless of specific backends; there's a large potential
> liability for what I consider zero additional functionality. The one
> case that's been brought forward as additional functionality enabled
> by the type-based decay, Alberto's INTERSECTS(user_geom,
> obscore.s_region), is caused by the IMHO invalid approximation of the
> coverage of spectra as points (which they clearly are not).
> 
> In practice, however, I think all serious ADQL translators do type
> inference.  So, it's not a big deal after all.  And to save us the
> time discussing matters further or, god forbid, introducing new
> optional features, I'd therefore propose to just go back to the old
> text (p.17 in ADQL 2.0):
> 
>  Note that if one of the arguments is a POINT, intersects is
>  equivalent to contains (with the point argument first).
> 
>        -- Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170908/72a9e13f/attachment-0001.html>