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.
Hello, I vote for solution #1. Most elegant in my mind if the CF convention for attribute standard_name can be tweaked to accommodate multiple standard names (.e.g., such as a space separated list l ?) regards, On Nov 2, 2011, at 10:45 AM, Jonathan Gregory wrote: > Dear Thomas et al. > > If I've understood correctly, two different solutions have been suggested to > the issue of duplicated status_flag variables. > > * Have only one status_flag variable, with flag_values and flag_meanings > attributes. This one variable will be pointed to by the ancillary_variables > attribute of several data variables. This means we need a new convention for > the standard_name attribute so that it can be associated with data variables > that may have various standard_names. > > * Have a separate status_flag variable for each data variable. In that case > the standard_name can be specific to the data variable. To avoid repeating > the definitions of flags, introduce a new convention to allow the flag_values > and flag_meanings attributes to be attached to a separate container variable > that can be pointed to by all the data variables. > > Clearly there are use cases that need attention in some way, but it would be > preferable to make no more than one change to the CF standard. Which of these > approaches is preferable, or are there others that people have in mind? > > Cheers > > Jonathan -ed Ed Armstrong JPL Physical Oceanography DAAC 818 519-7607
cf-satellite archives: