⇐ ⇒

[CF-metadata] bounds/precision for time axis

From: Jon Blower <j.d.blower>
Date: Thu, 3 Jun 2010 22:39:20 +0100

Hi Nan,

Yes, I think "resolution" is an appropriate term, thanks very much for
pointing this out. I think of resolution (loosely) as being the
accuracy to which something is knowable, and it's a property of a
measurement technique, not an actual measurement (is this right?). It
seems to fit my requirement.

I wonder if we can combine a new "resolution" attribute with Steve
Hankin's "point_spacing" attribute to solve the issue? I'm going to
take the liberty of modifying Steve's idea to not just indicate that an
axis is evenly-spaced, but also to provide the spacing.

E.g. for a typical OSTIA dataset, both "resolution" and "point_spacing"
might be "1 day". This effectively gives a gapless time axis: we have
information for all time instants from the start to the end of the time
axis.

In contrast, an NWP forecast might have "resolution" of "1 ms" (or
whatever... I don't know) but a "point_spacing" of 6 hours. The time
axis is therefore "gappy": we essentially have no information between
the snapshots and would have to interpolate to find a field at 03:00Z.

Does this sound reasonable? My worry is the subtle distinction between
"resolution" and "bounds/cell_methods", which I would have to think
through properly at some more sociable hour.

Cheers,
Jon

-----Original Message-----
From: Nan Galbraith [mailto:ngalbraith at whoi.edu]
Sent: 03 June 2010 21:23
To: Jon Blower; cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] bounds/precision for time axis

Hi Jon -

I think the term 'resolution' might be more correct in this case than
'precision' - These are the definitions we use, although I can't quite
find the source:

    * Resolution is the fineness to which an instrument can be read.
    * Precision is the fineness to which an instrument can be read
repeatably and reliably.

I'm also using the attribute 'C_format' - don't recall exactly which
convention
uses that, but it's a good way to indicate 'vagueness' - but I'm not
sure how
or if it could be used to indicate that the dates are only good to whole

days.

Cheers - Nan
> Hi Mike,
>
> This is useful, thanks. However, I'm not sure that this concept of
> "uncertainty" is exactly the same as my notion of "nominal precision"
> (maybe I've chosen a bad name). For example, I know for sure that an
> OSTIA daily analysis field is considered representative of a certain
> day, but the specification of exactly how the field is representative
is
> complex. This, to me, is not quite the same as saying that the field
> represents 12 noon on that day, plus or minus 12 hours. It's more
> "imprecision" than "uncertainty".
>
> Would you agree with this distinction?
>
> Cheers, Jon
>
> -----Original Message-----
> From: McCann, Mike [mailto:mccann at mbari.org]
> Sent: 03 June 2010 19:47
> To: Jon Blower; Steve Hankin
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] bounds/precision for time axis
>
> 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
>
>
>
>


-- 
*******************************************************
* Nan Galbraith                        (508) 289-2444 *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                                *
*******************************************************
Received on Thu Jun 03 2010 - 15:39:20 BST

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

⇐ ⇒