Re: Sessions at Trieste

Hi,

Still about the coordinate system and spherical distances:

>>[...]
>> 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).

===> You are right, Pat ! It can't be a function applied on a column.

>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).

But having positions expressed in different systems in a large table can really be a problem -- indexes cannot be used among other difficulties. Among the >10,000 tables stored in vizier, it happened only once that positions were stored in 2 systems (B1950 or J2000) in the same table. The practical solution we adopted was to create a couple of additional positions in one of the systems -- much more efficient to compute and store this once rather than re-compute this for all incoming queries. No need to change the FITS headers, just add the computed coordinates in J2000 in the relational table.

The question of the reference frame is in fact quite similar to the question of units: it could be possible to add a 'unit' column following a 'value' column, allowing collections of values stored with heterogenous units. But queries become much much slower if each comparison requires a computation, and indexation techniques can't help any more... Hence the necessity of getting the column metadata before submitting the query (cf TAP :-)

Francois

Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
Email: francois-at-astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 32
================================================================================