Re: [cf-satellite] [CF-metadata] Sharing quality flags amongmultiple variables

NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.

Dear all,

I have a similar issue for my sea ice motion product, stored in netCDF. It is 
based on satellite data, but I do not think it really matters for the 
discussion. 

Like winds, currents, and other "2D vector" quantity, my ice drift dataset is 
made of 2 variables. Be it distance/bearing, lat_end/lon_end, drift_x/drift_y: 
I need two netCDF variables to encode my vector.

My issue is then to associate a 'status_flag' variable with both 
sea_ice_x_displacement and sea_ice_y_displacement.

Currently, my "status_flag" variable (which uses flag_values and flag_meanings 
attributes) has standard name "sea_ice_x_displacement status_flag" but what I 
really would like is something like 
"sea_ice_x_displacement,sea_ice_y_displacement status_flag" (or any other 
extension the CF list agrees on) to inform a machine (or a human) that my 
status_flag applies to both components of my ice drift vector.

Cheers,
Thomas



----- Original Message -----
> Hi all:
> 
> a recap ...
> 
> When Chris stated this morning:
> 
> "I don't want to speak for Randy, but I know it is quite common in
> Level 2 data from the Earth Observing System to have quality variables
> where there is a one-to-one match at the pixel level between a given
> quality variable and 1 or more data variables. We see this case in
> AIRS Level 2 as well as MODIS Level 2 atmospheres products."
> 
> This is exactly what my problem is. (I am working GOES-R ground).
> 
> After reading through the chain of emails, it would seem that the way
> the current conventions read, one can use the "ancillary data" feature
> of the CF conventions to allow a ssigle set of quality flags to be
> associated with multiple variables (but you lose the software/machine
> interpretation of what the quality flags mean
> 
> OR
> 
> Use the "Flags" feature of the CF conventions that allows for
> software/machine interpretation of what the quality flags mean (but
> not have the ability to share quality flags.
> 
> Ideally, for our user communities, it would be best to have both.
> 
> Also note that at least in the case of GOES-R GS, there is no issue
> with keeping both the product data and quality variables in the same
> file.
> 
> very respectfully,
> 
> randy
> 
> 
> ---------- Original Message ----------------------------------
> From: "Lynnes, Christopher S. (GSFC-6102)"
> <christopher.s.lynnes@xxxxxxxx>
> Date: Tue, 1 Nov 2011 12:50:54 -0500
> 
> >A key point in this discussion is whether this quality-related
> >information should be intended to be solely for users to read, or
> >whether we ultimately want it to provide info that is actionable for
> >programs?
> >
> >Philosophically, I tend to prefer the latter, but OTOH am only too
> >aware of how much information needs to be embedded for programs to
> >correctly interpret quality variables. (It's harder than it looks...)
> >
> >On Nov 1, 2011, at 1:44 PM, Armstrong, Edward M (388M) wrote:
> >
> >> Hello,
> >>
> >> That assessment seems to be the crux of the problem. Its look like
> >> CF wants a specific quality variable standard name, an approach
> >> that won't work for one quality variable applicable to many other
> >> data variables.
> >>
> >> But the standard_name in not required, is it ? So a simple
> >> "comment:" statement could remind the user the data variables a
> >> particular quality variable is applicable for. Or could you have a
> >> list of standard_names in the quality variable (would require new
> >> CF "rules" ) ?
> >>
> >> On Nov 1, 2011, at 11:38 AM, Jonathan Gregory wrote:
> >>
> >>> Dear Upendra
> >>>
> >>>> On 11/1/2011 10:47 AM, Upendra Dadi wrote:
> >>>>> The same issue occurs with World Ocean Database which consists
> >>>>> of
> >>>>> mainly profile data. Each profile typically consists of several
> >>>>> variables measured along the depth. The quality flags used for
> >>>>> all
> >>>>> the variable are same.
> >>>
> >>>>> On 10/31/2011 12:12 PM, Randy Horne wrote:
> >>>>>> The current CF conventions dictate that quality flags are
> >>>>>> attached to specific variables. The implication is that
> >>>>>> comforming with CF conventions would require the same quality
> >>>>>> flags to be stored multiple times in our NetCDF product files.
> >>>
> >>> Quality flags are attached to variables using the
> >>> ancillary_variables att of
> >>> the data variable. If several data variables had the same quality
> >>> flags and
> >>> dimensions, they could all point to the same quality variable.
> >>> Perhaps the
> >>> problem is that the different variables have different standard
> >>> names, and
> >>> this means the quality variables would also have different
> >>> standard names
> >>> (and therefore could not be the same variable)? If that is the
> >>> problem, perhaps
> >>> we could find a way round it. Or have I missed the point?
> >>>
> >>> Best wishes
> >>>
> >>> Jonathan
> >>>
> >>> _______________________________________________
> >>> cf-satellite mailing list
> >>> cf-satellite@xxxxxxxxxxxxxxxx
> >>> For list information or to unsubscribe, visit:
> >>> http://www.unidata.ucar.edu/mailing_lists/
> >>
> >> -ed
> >>
> >> Ed Armstrong
> >> JPL Physical Oceanography DAAC
> >> 818 519-7607
> >>
> >>
> >>
> >> _______________________________________________
> >> cf-satellite mailing list
> >> cf-satellite@xxxxxxxxxxxxxxxx
> >> For list information or to unsubscribe, visit:
> >> http://www.unidata.ucar.edu/mailing_lists/
> >
> >Christopher Lynnes
> >Goddard Earth Sciences Data and Information Center, NASA/GSFC
> >301-614-5185
> >
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata@xxxxxxxxxxxx
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> 
> 
> 
> ..............End of Message ...............................-->
> 
> 
> 
> 
> _______________________________________________
> CF-metadata mailing list
> CF-metadata@xxxxxxxxxxxx
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

-- 
========================================== 
Thomas Lavergne 
Norwegian Meteorological Institute 
P.O.BOX 43, Blindern, NO-0313 OSLO, Norway 
Phone: (+47) 22963364  Fax: (+47) 22963380 
Email: t.lavergne@xxxxxx 
OSISAF HL Portal:     http://osisaf.met.no 
========================================== 



  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the cf-satellite archives: