<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Hi Markus,</div><div class=""><br class=""></div><div class="">I understand you already implemented spectral footprints with a very tiny CIRCLE:</div><div class="">that solves your own issue with your own database when doing smth like:</div><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;">INTERSECTS( s_region, POLYGON(…) )</span></div></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;">or even </span></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;">INTERSECTS( ObsCore1.s_region, ObsCore2.s_region)</span></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><br class=""></div><div class="">Then, the only remaining problem you have is to support something like:</div><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><span class="" style="font-variant-ligatures: no-common-ligatures;">INTERSECTS( s_region, POINT(...) )</span></div></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">In that case then use the same trick: make your ADQL translator</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">change the POINT into a small CIRCLE (e.g. radius 1E-7), and you are done.</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">Similarly with CENTROID.</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><br class=""></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">Notice please all the “your”s and “you”s in the sentences above...</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><br class=""></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">Luckily, in my case we are using a database that supports all that functionality.</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">No need to implement all those tricks…</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">In my case, everything is of datatype “geography”, yes, even the demonised POINTs.</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><br class=""></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">This difference between “your” case and “my” case</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">shows quite well why a standard should abstain from any implementation</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">details… let’s leave the implementation details to the implementors!</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><br class=""></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">Given the above, I think it is no problem to remove that confusing and</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;">platform-dependent text from the standards (both ADQL and TAP). Dave? Pat?</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;"><br class=""></div><div class=""><span class="" style="font-variant-ligatures: no-common-ligatures;">Alberto</span></div></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 07 Sep 2017, at 11:51, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear DAL,<br class=""><br class="">TL;DR: As the person who brought up the proposition to drop the<br class="">type-based decay of INTERSECTS to CONTAINS, I formally retract that<br class="">proposition. While I still think it's technically right (point made<br class="">below), it's not enough of a issue to warrant more optional features.<br class=""><br class="">On Wed, Sep 06, 2017 at 04:12:41PM +0100, Dave Morris wrote:<br class=""><blockquote type="cite" class="">So the text for INTERSECTS becomes :<br class=""><br class=""> "The arguments to INTERSECTS SHOULD be geometric expressions evaluating<br class=""> to either BOX, CIRCLE or POLYGON."<br class=""><br class=""> "If a service supports the additional INTERSECTS-POINT feature, then<br class=""> the arguments to INTERSECTS MAY also include POINT."<br class=""><br class=""> "If a service does not support the INTERSECTS-POINT feature, then<br class=""> the service MAY return an error when processing INTERSECTS with<br class=""> a POINT argument"<br class=""></blockquote><br class="">Again, my dislike of optional features that clients and users need to<br class="">know about to predict the behaviour of a service overrides all other<br class="">concerns. Let's not have that and keep it like it is now: *If* you<br class="">implement INTERSECTS, it has to decay, period. If you don't want to<br class="">do type inference, then don't implement INTERSECTS.<br class=""><br class="">Having said that, I cannot resist pointing out that...<br class=""><br class=""><blockquote type="cite" class="">On 2017-09-06 14:58, alberto micol wrote:<br class=""><blockquote type="cite" class="">Requiring, as stated in ADQL2.1, to interpret INTERSECTS as a CONTAINS<br class="">might be a valid suggestion for implementing the standard on a<br class="">specific technology, but the standard should not care of how<br class="">developers will implement that.<br class=""><br class="">Dropping INTERSECTS support for POINTs just because pgsphere cannot<br class="">cope well with it<br class="">is not the right way to go, other databases cope fine with that.<br class=""></blockquote></blockquote><br class="">...INTERSECTION with a point is a concept that needs explanation,<br class="">at the very least; just because some implementation gloss over the<br class="">oddity of the operation. <br class=""><br class="">I've not read up on how people doing computational geometry (or<br class="">whatever) define intersection. If you model them as set operations<br class="">(which is at least sensible), however, the situation is clear: CIRCLE<br class="">and POLYGON are *sets* of points, and a POINT is, well, a point.<br class="">Doing a set operation with a point as one operand is clearly<br class="">undefined as such.<br class=""><br class="">Now, you *can*, if you insist for practical reasons, define<br class="">polymorphous operators. For CONTAINS, that's at least<br class="">straightforwardly defined. There, it's is-subset-of for a set-valued<br class="">first operand, and is-element-of for a point-valued first operand.<br class="">For INTERSECTS, that's a lot more involved, as it in effect requires<br class="">mutating one operand (from point to set-of-points).<br class=""><br class="">Hence, ADQL 2.0 chose to define INTERSECTS in terms of CONTAINS. I<br class="">stand by my assessment that that's the only place in ADQL in which<br class="">you need to do type inference to define the operation (where I'll<br class="">admit that CONTAINS is a border case). It is that irreguarity that<br class="">bugged me, regardless of specific backends; there's a large potential<br class="">liability for what I consider zero additional functionality. The one<br class="">case that's been brought forward as additional functionality enabled<br class="">by the type-based decay, Alberto's INTERSECTS(user_geom,<br class="">obscore.s_region), is caused by the IMHO invalid approximation of the<br class="">coverage of spectra as points (which they clearly are not).<br class=""><br class="">In practice, however, I think all serious ADQL translators do type<br class="">inference. So, it's not a big deal after all. And to save us the<br class="">time discussing matters further or, god forbid, introducing new<br class="">optional features, I'd therefore propose to just go back to the old<br class="">text (p.17 in ADQL 2.0):<br class=""><br class=""> Note that if one of the arguments is a POINT, intersects is<br class=""> equivalent to contains (with the point argument first).<br class=""><br class=""> -- Markus<br class=""></div></div></blockquote></div><br class=""></body></html>