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 <[email protected]> ----- > From: John Graybeal <[email protected]> > Date: Mon, 1 Jul 2013 14:19:30 -0700 > To: [email protected] > X-Mailer: Apple Mail (2.1508) > CC: [email protected] > 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 <[email protected]> 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 > >> "[email protected]"<[email protected]> ----- > >> > >>> From: "[email protected]"<[email protected]> > >>> To: [email protected] > >>> 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 > >>> [email protected] > >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >> > >> ----- End forwarded message ----- > >> _______________________________________________ > >> CF-metadata mailing list > >> [email protected] > >> 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 > > [email protected] > > 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 > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
