<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>On a different, but somewhat related topic:<br></div>Assuming that users will not mix equatorial and Galactic coordinates<br></div>in the DISTANCE function, there is indeed no need for a coordinate<br></div>system. But the implicit assumption is that the function has spherical<br></div>coordinates are input and returns an angular distance.<br></div>Woudl it not be better to be explicit about this and call the function<br></div>SPHERICAL_DISTANCE or ANGULAR_DISTANCE? I know, it's a bit<br></div>of a mounthful, but ANGDISTANCE or ANGDIST would work, too.<br></div>By doingh that we are explicit about what it is that we are talking about<br></div>and don't allow spherical coordinate systems to lay exclusive claim to<br></div>the concept DISTANCE.<br></div>And it leaves the door open to later define distances for Cartesian<br></div>coordinates or terrestrial coordinates in linear units.<br><br></div>Cheers,<br><br></div> - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Mon, Apr 11, 2016 at 1:57 PM, Patrick Dowler <span dir="ltr"><<a href="mailto:pdowler.cadc@gmail.com" target="_blank">pdowler.cadc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TL;DR - I think that we should redefine all the geometry functions<br>
without coord sys now and (since overloading seems to be OK) we can<br>
keep the old deprecated ones if we have to. Then the 2-arg DISTANCE<br>
function with point args is my preferred solution. I don't see this<br>
strictly as syntactic sugar to be used instead of a crafty CONTAINS<br>
(equiv as a predicate) because the user can also add DISTANCE(...) to<br>
the select list.<br>
<br>
Long version:<br>
<br>
While I agree that something like DISTANCE is preferrable to XMATCH<br>
because it correctly conveys exactly what is going on, I don't like<br>
the 4-arg version because it foils implementations that have spherical<br>
geometry indexing, or at least makes them really messy with new<br>
failure modes:<br>
<br>
We have several catalogues in our TAP service with the coordinates in<br>
a column described with xtype="adql:POINT" (lets ignore the details of<br>
the adql prefix for now). If the query on those tables uses that<br>
column, the relevant indexing comes into play. It is true that the<br>
tables also have separate RA and DEC columns and in principle I could<br>
detect DISTANCE(RA, DEC, uploaded.c1, uploaded.c2) and replace RA, DEC<br>
with the POS column, but what do I do if:<br>
<br>
- query refers to the wrong columns in the table (e.g. DISTANCE(foo,<br>
bar, uploaded.c1, uploaded.c2)<br>
- query just gets them in the wrong order (e.g. DISTANCE(DEC, RA,<br>
uploaded.c1, uploaded.c2)<br>
<br>
I would be inclined to have the job fail rather than run it. It makes<br>
me wonder why we would make the user put the two coordinates together<br>
(and possibly make mistakes) when I have already put them together<br>
correctly for them.<br>
<br>
On the other hand, if a service has a table with just the RA and DEC<br>
columns they can still advertise in the TAP_SCHEMA that they have a<br>
POS column, and then when they see DISTANCE(POS, ...) they can easily<br>
replace POS with whatever reference to RA and DEC are correct and<br>
optimal. It is always easier to expand a single symbol into the<br>
internal implementation than to go the other way. Sure, upload tables<br>
may have a column with point(s) or separate columns with coordinates,<br>
so with DISTANCE(<point>, <point>) one would typically write<br>
<br>
DISTANCE(POS, POINT(uploaded,c1, upload.c2))<br>
<br>
A 2-arg DISTANCE function and services declaring a POS column (maybe<br>
instead of RA and DEC) are adding value and making it easier for the<br>
user. A 4-arg DISTANCE function makes adding value impossible and<br>
introduces ways to make essentially incorrect queries (admittedly,<br>
there are plenty of ways to do that already :-).<br>
<br>
So, I am a fan of the 2-arg DISTANCE but not of the { } syntax, which<br>
strikes me as non-SQL. In PG, for example, you can write geometry in<br>
internal syntax like that but (i) is has to be a string and (ii) you<br>
almost always have to provide a cast to get the value you want. Worst<br>
case is that users have to write DISTANCE(POINT(c1, c2), POINT(c3,<br>
c4)) if the service/implementation doesn't provide the added value<br>
necessary.<br>
<br>
PS-Yes, I means exactly that POINT function with 2 args. We already<br>
realised a long time ago that including the coordinate system in the<br>
functions was a huge mistake and since then we have been working to<br>
remove that (eg SIA-2.0 and DALI-1.1 do not include it and DALI<br>
defines point exactly like above, and the next TAP revision will be<br>
consistent with that). I personally think that we should just redefine<br>
all the geometry functions without coord sys now and (since<br>
overloading seems to be OK) we can keep the old deprecated ones if we<br>
have to.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Patrick Dowler<br>
Canadian Astronomy Data Centre<br>
Victoria, BC, Canada<br>
</font></span></blockquote></div><br></div>