Expressing 2- and 3-D coordinates
francois at vizir.u-strasbg.fr
Wed Dec 14 04:26:59 PST 2005
About the question of arrays in cells -- as far as VOTable is concerned
the question is not the _possibility_ of storing the position as a vector
(it's quite possible, Alberto !) but the _requirement_ of grouping the
components of the position, their error, etc in dedicated structures
that cannot always be compatible with the VOTable definition.
There are two main problems:
-- it happens that only 1 component of the position is present (e.g. meridian
catalogs measure the RA, not the Dec).
-- an array is not just a set of numbers -- in VOTable it's required
that all elements are expressed with the same data type (e.g. double)
and expressed with the same unit (this makes physical sense, too).
It's obviously a problem for the spherical 3D coordinates
(2 angles and a distance); errors ellipses are also problematic
One way of resolving this dilemna in VOTable was proposed at the Spanish
IVOA meeting in last October, with a convention on the contents of the
"utype" attribute (the attribute which aims at describing exactly what
the column represents, as opposed to the broad classification provided
by the "ucd" attribute): use conventions similar to the XPath/XQuery
syntax to refer to the exact parameter or quantity described in a data
model. With such a convention it becomes possible to use in VOTable either
the vector representation, or the individual components:
-- <FIELD name="pos" type="double" arraysize="2" ucd="pos.eq" unit="rad"
implies that the position is stored as a 2D vector e.g.
-- <FIELD name="RA" type="double" ucd="pos.eq.ra" unit="rad"
implies that the column contains the first component of the position e.g.
The contents of the utype becomes somewhat indigest and not intuitive --
but on the other hand it has the decisive advantages of:
-- non-ambiguity: "RA" becomes "the first component of the 2-D value of the
astrononomical coordinate system defined in the STC model under the
designation 'J2000-OPTICAL-ET'") and a program can easily gather the
various components of a datamodel refered in a VOTable and take the
appropriate action (even ask a robotic telescope to point successively
to the positions given in the table rows...)
-- transformability: the relevant columns of each row can be converted
into the schema defined by the data model (e.g. the STC model)
-- verifiability: if necessary, check that all the required parameters
of the data model are present, with the proper data types, etc.
This proposal was not accepted at the last IVOA meeting -- but I feel it's
really worth to consider this possibility of bridging the existing data models
with large data sets expressed as VOTables. Any comments ?
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
More information about the votable