⇐ ⇒

[CF-metadata] Fwd: how to represent a non-standard error

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 3 Jul 2013 14:57:43 +0100

Dear all

OK, I agree that if it's useful to compare them, then they should be described
in a standardised way.

Why is this *not* a standard error? I suppose that to be described as a
standard error it should be a number you could regard as the standard deviation
of the true value around the stated value. If it's not that, are there other
ways you would use such a number?

Best wishes

Jonathan

----- Forwarded message from John Graybeal <john.graybeal at marinexplore.com> -----

> From: John Graybeal <john.graybeal at marinexplore.com>
> Date: Mon, 1 Jul 2013 14:19:30 -0700
> To: ngalbraith at whoi.edu
> X-Mailer: Apple Mail (2.1508)
> CC: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Fwd: how to represent a non-standard error
>
> Yes please, I've wanted the ability to specify something like "error_estimate" for some time too. Even if the calculations are not done in exactly the same way -- they could even be off by an order of magnitude -- being able to compare them is meaningful. And it's extremely valuable to be able to answer the query "Which variables have error estimates?"
>
> So if we can some up with a standard way to represent this it will be extremely helpful.
>
> John
>
> On Jul 1, 2013, at 13:00, Nan Galbraith <ngalbraith at whoi.edu> wrote:
>
> > I think that these are fairly important QC checks for wind and current
> > data, and that they deserve to have standard names to make them
> > more useful. Although the algorithms may differ between instruments,
> > and may even be proprietary, these variables are often the most useful
> > way to provide information about the reliability of the geophysical
> > measurements.
> >
> > I had asked about the best way to label this parameter for ADCP data
> > several years ago, but I wasn't able to explain why standard_error wasn't
> > appropriate (it's a little outside my field).
> >
> > Could we use a standard name modifier like 'instrument_error',
> > or even just 'error', to convey the meaning of instrument-provided
> > error information? That would be much simpler than requesting a
> > name for each instrument type (although I suppose there may be
> > only a handful of those).
> >
> > Thanks - Nan
> >
> > On 7/1/13 1:10 PM, Jonathan Gregory wrote:
> >> Dear Randy
> >>
> >> If it is very product-specific, is it really a geophysical quantity which needs
> >> a standard name? I mean, are there data from several sources for this quantity
> >> which should be regarded as comparable, and which therefore should have a
> >> common standard name?
> >>
> >> If the answer is Yes, then I would suggest you propose a standard name which
> >> explicit names the algorithm, like e.g. isccp_cloud_area_fraction.
> >>
> >> Best wishes
> >>
> >> Jonathan
> >>
> >> ----- Forwarded message from "rhorne at excaliburlabs.com"<rhorne at excaliburlabs.com> -----
> >>
> >>> From: "rhorne at excaliburlabs.com"<rhorne at excaliburlabs.com>
> >>> To: cf-metadata at cgd.ucar.edu
> >>> Date: Mon, 1 Jul 2013 08:28:15 -0400
> >>> Subject: [CF-metadata] how to represent a non-standard error
> >>>
> >>>
> >>>
> >>> Folks: the GOES-R ground system generates a derived motion winds product.
> >>> Accompaning each wind speed& direction in the product is the amount of
> >>> error associated withe the vector. This error is not a standard_error, but
> >>> an error estimate based on a custom algorithm. Because this is not a
> >>> standard_error, it would seem that using a standard_error standard_name
> >>> modifier would be misleading. Any thoughts on how to represent this
> >>> product-specific error in the NetCDF file ? (The best idead I could come up
> >>> with so far is to establish an ancillary data relationwhip between the wind
> >>> speed/direction variables and the error variable, and use the error
> >>> variable's long_name to describe the error) very respectfully, randy
> >>> _______________________________________________
> >>> CF-metadata mailing list
> >>> CF-metadata at cgd.ucar.edu
> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>
> >> ----- End forwarded message -----
> >> _______________________________________________
> >> CF-metadata mailing list
> >> CF-metadata at cgd.ucar.edu
> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>
> >
> >
> > --
> > *******************************************************
> > * Nan Galbraith (508) 289-2444 *
> > * Upper Ocean Processes Group Mail Stop 29 *
> > * Woods Hole Oceanographic Institution *
> > * Woods Hole, MA 02543 *
> > *******************************************************
> >
> >
> >
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> ------------------------------------
> John Graybeal
> Senior Data Manager, Metadata and Semantics
>
> T +1 (408) 675-5545
> F +1 (408) 616-1626
> skype: graybealski
>
> Marinexplore
> 920 Stewart Drive
> Sunnyvale, CA
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

----- End forwarded message -----
Received on Wed Jul 03 2013 - 07:57:43 BST

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

⇐ ⇒