TAP 1.1 comment on INTERSECTS and point-valued columns

[Patrick Dowler]

Alberto,

You can certainly implement extended functionality like that - it is
essentially overloading the function to support alternate signature
(arg type/number). There are other cases like that within ADQL but
TAPRegExt-1.0 did not include function argument types/numbers ... I
don't think we have figured out what will be needed in TAPRegExt-1.1
but since it describes TAP and query language features it has to come
at the tail end of new TAP and ADQL specs.

Pat

On 13 September 2017 at 01:56, alberto micol <amicol.ivoa at googlemail.com> wrote:
> 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
>



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