TAP 1.1 comment on INTERSECTS and point-valued columns

[alberto micol]

Thanks Pat. Probably (I do not remember the discussion) Szalay had a point back in 2009,
but, since, things have evolved. By now, SQLServer supports all kinds of geometries or
geographies (the SQLServer datatypes).  It is certainly no more a problem to handle points,
as it is not the case e.g. for multi-polygons.

I will be pleased if you could remove that sentence from TAP 1.1 as you suggested, given
that indeed it is the ADQL standard that should cover those aspects, and not TAP.

This brings me to a different issue: the DISTANCE function we will implement
DISTANCE( arg1, arg2 )
will allow both arguments to be POINT, CIRCLE, POLYGON, UNION of POLYGONs, etc.
For example it will be possible to use: DISTANCE( s_region, CIRCLE(‘’, 10, 20, 1) ),
or even: DISTANCE( ObsCore1.s_region, ObsCore2.s_region )
 
At the contrary, in ADQL the DISTANCE function can only work on two points.

Is there a way to declare that a TAP service supports such extended DISTANCE functionality?

Many thanks,
Alberto


on SQLServer can 

> On 11 Sep 2017, at 18:20, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> I recall a log time ago (PR-ADQL-2.0 in 2009) having this same
> discussion and Alex Szalay made the argument that treating point like
> the other geometries was a bad idea and that many geometry systems do
> not do that for reasons that are pretty much what Markus said above
> about set operations. I can't recall the details but I do recall that
> we made several compromises to get ADQL-2.0 done and most of them have
> come back to haunt us.
> 
> One of the design principles for the transition to 2.1 has been to
> test and evaluate how various things work in different database
> engines and be wary of things that are particularly painful. We have
> accepted that tap services will have to parse and re-write ADQL to SQL
> but we also don't want to make that any harder than possible and we
> don't want to force everyone into a few back-end choices.
> 
> Having said that, I am happy to remove the text entirely from TAP-1.1
> and just defer to whichever ADQL version people decide to implement.
> 
> Pat
> 
> On 8 September 2017 at 04:29, alberto micol <amicol.ivoa at googlemail.com> wrote:
>> 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
>> 
>> 
> 
> 
> 
> -- 
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada