bonnarel at alinda.u-strasbg.fr
Wed Sep 26 04:02:57 PDT 2007
this is my last chance to answer this before the TimeSeries discussion at the Interop
Your serialisation proposal is quite good in general and specially in the case
where the Time coordinate values are exactly the same for both colors .But here in
our implementation with Mireille we took benefit of our organisation in two tables
to suppress time instants where actually no valid value was known for one of the colours.
(value coded by 99.9 or whatever). Actually when two axes are sampled independantly (here
time and spectral) our two table solution is clearer. I suppose that for time
series it is not so seldom because with one single telescope and by changing
the filter we never have accuratly the same time of observations for the
two colors. In conclusion I think for VOTABLE implementations we have to let
some flexibility in the organisation. Correct use of the utypes should allow
a client software to deal with both.
<From dtody at aoc.nrao.edu Fri Aug 10 20:33:50 2007
<> Notice that in the VOTABLE we considered the example as a SED with
<> two segments (one for each color). Although they are not listed in
<> the Spectrum Reference document we added the head element SED in
<> the utypes and replace Spectrum by TimeSeries everywhere. these new
<> utypes can be easily inferred from the xml schema in the general SED
<> case when segments are different from the single spectrum case.
<For a time series with multiple flux values per time coordinate,
<why not represent this as a single segment? Normally this would
<be a single observation, and all the other metadata is the same.
<I should think that multiple segments would be used for observations at
<different times, much as for a multi-segment spectrum, the different
<segments might represent different regions of spectral coordinate
<(e.g., as for an Echelle).
<If we take a time series with multiple flux values per time sample,
<and serialize it in TSV, one would expect to see something like
< TimeValue Flux1 FluxErr1 Flux2 FluxErr2
< 167.1178 5.105 0.162 5.617 0.080
< 181.0784 5.392 0.135 5.609 0.079
<which would be the direct analogue of a VOTable representation which
<has mutliple flux values per time sample, and would be what we get
<if we write out this same time series in CSV/TSV instead of VOTable.
<In this case the VOTable would contain multiple GROUPs with UTYPE
<spec:SED.TimeSeries.Data.FluxAxis, however I don't see any problem
<with this. For UTYPE the important thing is that the UTYPE uniquely
<identify the field of a data model; this does not mean that we cannot
<have multiple instances of a data model in a single namespace, such
<as a VOTable.
< - Doug
Francois Bonnarel Observatoire Astronomique de Strasbourg
CDS (Centre de donnees 11, rue de l'Universite
astronomiques de Strasbourg) F--67000 Strasbourg (France)
Tel: +33-(0)3 90 24 24 11 WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25 E-mail: bonnarel at astro.u-strasbg.fr
More information about the dm