I'd like to jump into this (and hopefully not expose my ignorance).
I have a similar situation where it's not error that I'm tracking, but
instead data quality, and I guess that I've been thinking kind of along
Bryan's line here. I'm recording realtime buoy observations (wind speed,
direction, wave height, etc) and with to each observation a quality flag
is assigned, and right now I do this by keeping another variable attached
to the parameter in question. For example, here's an example from a
current meter file
float current_speed(time, depth, lat, lon) ;
current_speed:long_name = "Current Speed" ;
current_speed:standard_name = "sea_water_speed" ;
current_speed:short_name = "CSPD" ;
current_speed:scale_factor = 1. ;
current_speed:add_offset = 0. ;
current_speed:_FillValue = -999.f ;
current_speed:units = "m/s" ;
current_speed:valid_range = 0.f, 10.f ;
current_speed:calibration_coeffs = 0., 0.2933, 0., 0. ;
current_speed:epic_code = 300 ;
byte current_speed_qc(time, depth, lat, lon) ;
current_speed_qc:long_name = "Current Speed Quality" ;
current_speed_qc:short_name = "CSPDQ" ;
current_speed_qc:scale_factor = 1. ;
current_speed_qc:add_offset = 0. ;
current_speed_qc:_FillValue = -128b ;
current_speed_qc:units = "none" ;
current_speed_qc:valid_range = -127s, 127s ;
current_speed_qc:quality_good = 0b ;
current_speed_qc:sensor_nonfunctional = 1b ;
current_speed_qc:outside_valid_range = 2b ;
If the data were only bad when it was outside the valid range, there would be no
need for the quality variable, but there are cases where the data actually is
within the valid range, but we still believe it to be bad. So right now I basically
have a quality variable for each geophysical parameter that I track. I've been kind
of wondering for a while how exactly this would fit into CF... I'm just tacking
on the letters "_qc" for each quality variable, but having a CF attribute
formally identifying it as just a quality variable would certain be easy
to do. But I'm open to other suggestions, and am currently in the middle of a push
to move my data into total CF compliance, so if there's a better way for me to do
this, I'm all ears.
On Thu, 20 Mar 2003, Bryan Lawrence wrote:
>Hi Jonathan
>
>> variables. However, I am not convinced about introducing a linking
>> attribute, because I don't think the relation is so close that it needs to
>> be given this special status.
>
>ok, I can accept that argument but ... see below
>
>> In this particular case, you can look for another variable with the same
>> spatiotemporal metadata and a standard_name which contains the original one
>> as a pattern. That would be very general.
>
>... but I had got the thought from the previous emails that we didn't want to
>enforce "error" into standard names ... and I think it would introduce a new
>problem:
>
>My radiosonde example is still a good one, and it's real:
>
>For each measurement in a profile I have a number which is an error (which
>might be a physical error quantity but is more likely a percentage). So, for
>an individual radisonde profile, say of humidity, then I have the
>measurement, and an error (let's say a percentage, which increases with
>height). So, I can see that I could have two variables in the file which are
>the humidity and the error (percentage).
>
>I could then produce a climatology from a year's measurements, and now the
>error of interest is the standard error associated with the variance between
>measurements within the month and it has rather different units than the
>error did in the previous case, still with the same names for the variables
>if we were trying to introduce an error standard name for every standard name
>... (have i misundestood this point?).
>
>The key point here is that different communties have rather different idea of
>what we mean by an error ... even with the same source data ... albeit at
>different stages of maturity.
>
>I would have thought it would have been cleaner to have an optional link
>between two variables ... software could simply fail gracefully if the link
>was broken. This is nothing more than a "data hyperlink" ...
>
>... but I dont feel strongly about this, as long as we can find a sensible way
>of doing it ...
>
>Bryan
>
>
--
John Evans
johnevans at acm.org
Received on Thu Mar 20 2003 - 07:56:02 GMT
