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 ==========================================
cf-satellite archives: