Nan Galbraith wrote:
Benno Blumenthal wrote:
This is not just a model problem -- current meters once upon a time
calculated average speed and instantaneous direction, which messed up
calculations of component velocities. Also, thermisters have thermal
mass, also introducing a lag with respect to other "simultaneously"
measured quantities.
We are just beginning to describe data better -- this is no time to
perpetuate mistakes.
Jonathan Gregory wrote:
The CF convention also provides cell_methods, which is an attribute
of the
data variable, to indicate how the data values are descriptive of the
variation
within cells (instantaneous, mean, integral, etc.). This information
is an
important complement to the coordinate information.
Cell methods applied to data variables are - or could be - the most
clear and efficient way to describe sampling schemes of observational
data - they just don't (yet) go far enough.
There's generally one clock in an instrument, and the single value it
records at each time step may need to be interpreted differently with
regard
to each measured variable - but is that a reason to generate separate
time
variables for each one? I don't think that can be justified in most
cases,
certainly not for long time series data sets; problems arise when there's
clock drift and times have to be adjusted - it seems much safer to keep a
single time variable, and extrapolate times for specific measured
variables using some kind of standard attributes.
As Benno mentioned, some instruments - not just old current meters, but
new ones, and most anemometers - still record a single direction and an
averaged speed. New instruments also record component velocities,
calculated with more frequently sampled, unrecorded direction, but
we carry along the recorded, sub-sampled directions as a check on compass
health.
Also, in real time data streams, the sample scheme preferred by most
or all
real time data aggregators has winds accumulated only over the last 10
minutes of an hour, while the other parameters are measured continuously
and averaged.
It would be useful to us to expand the cell methods, or to define
another attribute, with standard terms to describe the position of a
data variable measurement
relative to the time of the record. This seems to me to be preferable
to suggesting
that everyone use center time, and much more efficient than generating
multiple
time variables.
I don't see why this would in any way compromise the description of
observational
data, as long as there is a standard agreed upon for it.
Cheers - Nan
I agree, you make the case better than I did. There can be subtle
differences in the way a coordinate is used. A model run "forecast time"
is a good example of this. It would be very problematic if all the
variables output at a model time step didnt all have the same forecast
time. Similarly, all of the observations from a metar report should all
have the same observation time. This is the common way that people want
to find / view this data.
More sophisticated users / algorithms want to take into account more
detail on how the quantity was measured, averaged, accumulated, etc. We
want this metadata in the file also, and associating it with the
coordinate or with the data variable are 2 possible ways, both have
pluses and minuses. At the moment, I would lean toward the latter. But
perhaps we need to generate some specific examples.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
