On 2008-5-14 12:02, Francois Ochsenbein wrote:
> Even though I'm willing to compromise, let me just comment a bit more
> on spherical distance functions, summarized by the 2 alternatives
> DISTANCE ( POINT( a.coordsys, a.x, a.y), POINT( b.coordsys, b.ra, b.dec))
> and
> sphericalDistance(a.ra, a.dec, b.ra, b.dec)
>
> -- even though the functionnalities are similar, I'm not convinced
> sphericalDistance must be dropped -- the DISTANCE requires the
> knowledge of the coordinate system which is not easy to find
> in most, if not all, of the tabular catalogues available right now
> (in practice it's just defined in some explanatory text) -- while
> the sphericalDistance just assumes a common coordinate system.
But that is the problem: what if the two positions are expressed in different coordinate systems, which could be the case for (the standard example of) an uploaded user table and a table provided by the service.
> -- in terms of implementation, the sphericalDistance function is
> independent of any region / geometry / STC -- it is just a
> math function. Therefore why not adding this function ?
>
> By the way, in the DISTANCE expression above, the term "a.coordsys"
> tends to say that a column in a table could contain the coordinate
> system and that this system could be different in different rows
> of a table -- hopefully that is NOT true, and the 'coordsys' would
> better be seen as a property of a column in a table, written e.g.
That is true - it does say there should (at least logically) be a column with
the coordinate system and in most cases the value would be constant for the
whole table. However, that to me is the nature of SQL: columns do not have
these extra attributes.
> POINT( coordsys(a.x), a.x, a.y)
That looks nice enough, except that in SQL, that function would get evaluated and inside the function implementation you would see the value of a.x eg a floating point value; you would not know which column was actually used and could not do anything except return a constant value. This is assuming one implemented that function in the database, which is one of our design constraints. (To be syntactically correct in SQL, that is a function that takes a numeric value and returns a string).
Finally, allow me to relate the example of the collection of data from SCUBA
on the JCMT telescope. Some of the data is described with B1950/FK4 and some
with J2000/FK5 coordinate systems, yet it all is part of one collection
driven by ingesting metadata from FITS headers. They are legal and correct
values. Modifying the FITS headers and re-archiving ~half of the files was
not a feasible option. I'm not saying it is a great idea to do this, just
that it happens. If the ADQL spec were to implicitly not allow such a table
(to be queried) then I think we would be in trouble, because SQL does allow
it (and people would just put the coordsys, or units, or whatever, in another
column if they had to).
> And as another aside, shouldn't a 'coordsys' property applied on a
> POINT exist, besides the LONGITUDE and LATITUDE properties ?
Yes, Mark Taylor also commented on that and it is true that we should have that function. I think it applies to all geometry types since they all have a single coordinate system included, eg
<coordsys_extractor> ::= COORDSYS <left_paren> <geometry_expression> <right_paren>
and it should be a string.
> Also, about the RECTANGLE definition in section 2.3.2.2.5.11 (could it be
> possible to get rid of such ridiculously wide numbers?), the text mentions
> "ranges in longitude and latitude" -- which means that a box cannot
> contain any of the poles. Isn't a rectangle just a particular polygon,
> joined by great circles ?
I personally think of RECTANGLE as just a short form way to specify a POLYGON, where vertex coordinates are re-used in a particular pattern. But yes, it is a polygon with great circle edges and not a range of long/lat. I guess we weren't clear on that, or possibly ambivalent. (I think I suggested at one point that we get rid of it entirely, but we kind of forgot about it :-)
So, do we simply remove RECTANGLE or define it explicitly as a short-cut for making a particular polygon? ... which is generally only meaningful when small-ish and near the equator because elsewhere it is not really a rectangle :-)
-- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2008-05-14Z22:15:26