Hi all -

Here's the description of the error_velocity recorded by an ADCP; this text
is taken from the US-IOOS current QC manual that was recently published,
at http://www.ioos.noaa.gov/qartod/currents/qartod_currents_manual.pdf.

Error velocity is a key QC  parameter that derives from the 4-beam
> geometry of an ADCP. Each pair of opposing beams provides one
> measurement of the vertical velocity and one component of the
> horizontal velocity, so there are two independent measurements of
> velocity that can be compared. If the flow field is homogeneous, the
> difference between these velocities will average to zero. The error
> velocity can be treated as an indication of errors in the horizontal
> velocity measurements. This test is applied to each depth bin.

I wonder if a single standard name or modifier could be used for many types
of non-standard error variables, with an attribute identifying the type of calculation
used to generate the value.

Regards - Nan

On 7/3/13 9:57 AM, Jonathan Gregory wrote:
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



--
*******************************************************
* Nan Galbraith        Information Systems Specialist *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                 (508) 289-2444 *
*******************************************************


_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to