NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: