Expressing 2- and 3-D coordinates

Anita Richards amsr at jb.man.ac.uk
Wed Dec 14 05:04:29 PST 2005


We already use arrays e.g. in SIAP
<FIELD name="naxis"      ucd="VOX:Image_Naxis"           datatype="int" 
arraysize="2" />

The requirements which I would see as emerging are
1) In the above example, FITS images can have >2 axes, e.g. additional 
frequency and polarization axes (which may have only one pixel, but that 
is not the point)
2) For the Char model, some fields can either be a single value or a range 
(e.g. spatial resolution)
- so can an arraysize be variable?
    * in any given VOTable? Or would it have to be set instance by
      instance?
    * In the schema, to allow the case above?

At present, 4-axis images work fine in SIAP except that it ignors axes 3 
and 4 - but nothing 'breaks' so that's OK.

thanks
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AstroGrid Astronomer
MERLIN/VLBI National Facility, University of Manchester, 
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. 
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).


On Wed, 14 Dec 2005, Francois Ochsenbein wrote:

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



More information about the dm mailing list