[CF-metadata] Cell bounds associated with coordinate ... (in situ data)

From: John Caron <caron>
Date: Thu, 19 Nov 2009 17:45:36 -0700

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.
Received on Thu Nov 19 2009 - 17:45:36 GMT