Expressing 2- and 3-D coordinates

[Francois Ochsenbein]

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"
 utype="stc:AstroCoords[coord_system_id='J2000-OPTICAL-ET']/Position2D" >
implies that the position is stored as a 2D vector e.g. 
  <TD>187.2779 2.0524</TD>

-- <FIELD name="RA" type="double" ucd="pos.eq.ra" unit="rad"
utype="stc:AstroCoords[coord_system_id='J2000-OPTICAL-ET']/Position2D/Value2(1)"
>
implies that the column contains the first component of the position e.g.
  <TD>187.2779</TD>

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 ?

Cheers, 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
================================================================================