⇐ ⇒

[CF-metadata] bounds/precision for time axis

From: McCann, Mike <mccann>
Date: Thu, 03 Jun 2010 11:46:42 -0700

Hi Jon,

The OceanSITES data management team has recognized a desire to include an
attribute named "uncertainty" for all of our in situ measurements that are
in our netCDF files (that also follow the CF convention).

We chose the attribute "uncertainty" after much discussion around terms such
as "precision" and "accuracy" because we felt that "uncertainty" encompasses
several aspects of metrology and is more usable and simple to understand for
the consumers of the data.

This attribute can also be extended to the coordinate variables, e.g. If the
precision of my clock and upstream sampling techniques was 5 seconds I'd
assign 5 to the .uncertainty attribute on my time coordinate.

Would this approach work for your data?

-Mike



On 6/3/10 1:53 AM, "Jon Blower" <j.d.blower at reading.ac.uk> wrote:

> Thanks Steve, I agree that a "point_spacing:even" attribute would be
> helpful to clients.
>
> However, I think that the question of point spacing is separate to that
> of nominal precision. A time axis may be evenly spaced with one point a
> day, but the time axis values could be considered instantaneous
> (00:00:00.000Z), or each timestep could be considered "representative"
> of the whole day.
>
> I guess the combination of "cell_methods=cell" and "point_spacing:even",
> plus the separation between the first two points along the axis might
> together give the nominal precision.
>
> Perhaps instead of "point_spacing=even" we could have
> "regular_point_spacing=1.0" to make things slightly easier on clients?
> (Irregular axes would simply omit the regular_point_spacing attribute.)
>
> (I worry a little that this mechanism wouldn't allow a nominal precision
> of a month or year, which might be common for palaeo data, since months
> and years are not of exactly equal length.)
>
> Cheers, Jon
>
> -----Original Message-----
> From: Steve Hankin [mailto:Steven.C.Hankin at noaa.gov]
> Sent: 02 June 2010 22:58
> To: Jon Blower
> Cc: Jonathan Gregory; cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] bounds/precision for time axis
>
>
>
> Jon Blower wrote:
>> Dear Jonathan,
>>
>> Yes, I take your point. Another option would be to allow a simple
>> attribute on a time axis "nominal_precision" or something similar,
> which
>> could take values like "1 day", "1 month" etc. This could be in
>> addition to the bounds and cell_methods attributes.
>
>> The problem with
>> using the bounds/cell_methods approach in isolation is that it
> requires
>> a client to look at the bounds for every point along the time axis to
>> verify that the bounds for each point is the same length.
>>
> Hi Jon,
>
> This comment applies equally to spatial axes; as-is a CF client
> application must examine the full coordinate axis and its bounds in
> order to determine if an axis is regularly spaced whether time or
> space. And yes, this is a particularly acute problem for time axes,
> where it is not uncommon to have many thousands of points in a CF
> dataset.
>
> There have been discussions in the past of the merits of a
> "point_spacing" attribute:
>
> my_axis:point_spacing = "even";
>
> I'd be totally supportive of adding this attribute to CF, myself. It
> offers significant efficiencies to clients and it addresses your
> question reasonably well (to quickly infer a nominal spacing from the
> axis coordinates or its bounds).
>
> - Steve
>> Best wishes,
>> Jon
>>
>> -----Original Message-----
>> From: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] On Behalf
> Of
>> Jonathan Gregory
>> Sent: 02 June 2010 19:13
>> To: Jon Blower
>> Cc: cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] bounds/precision for time axis
>>
>> Dear Jon
>>
>> If we decide to let cell_methods indicate "vagueness" I don't think
> it's
>> a
>> problem if the bounds themselves are precise. The precision is
> somewhat
>> irrelevant, as you say, but it shouldn't be misleading in view of the
>> cell_methods. Changing cell_methods is a small alteration to the CF
>> standard,
>> whereas introducing alternative ways of representing time is a large
> and
>> complex change, which would require substantial alteration to software
>> as well.
>>
>> Best wishes
>>
>> Jonathan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
Received on Thu Jun 03 2010 - 12:46:42 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒