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