TAP 1.1 comment on INTERSECTS and point-valued columns

[Markus Demleitner]

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