Nan, Tom sent multiple emails regarding different variables / standard names, and I think perhaps my reply was in reference to a different email than the one you replied to. My reply below was referring to a variable containing “Snow Melt Onset” data. Here’s the relevant text.
Layer 2: Snow Melt Onset (melt onset condition at each sea ice covered pixel at start of melt season) 3000: no melt onset 3010: current melt onset 3011: future melt onset 3061-3245: day of year on which melt began I think the basic issue was that multiple types of information were being packed into a single variable, and done in a non-separable fashion. I believe a variable such as this is too complicated and specialized to be given a standard name. If there was one variable containing the date of melt onset, and another containing the status flags, I could see the first meriting a standard name (if there isn’t an appropriate one already). It seems to me that the status flags would still be too specialized to merit their own standard name. Grace and peace, Jim Visit us on Facebook Jim Biard Research Scholar Cooperative Institute for Climate and Satellites NC North Carolina State University NOAA's National Climatic Data Center 151 Patton Ave, Asheville, NC 28801 e: [email protected] o: +1 828 271 4900 On Nov 19, 2013, at 10:46 AM, Nan Galbraith <[email protected]> wrote: > Hi all - > > I have a couple of minor problems with the solution that's been proposed > for this question. Maybe I'm not understanding how this data will be > represented, > but it sounds like the actual melt conditions will be encoded into a variable > that has to be masked to extract the values. If that's correct, I think we > can > do better than calling this a status_flag and suggesting a long name be used > to describe the data. > > First of all, while it's true that data can be included in a CF file without > a standard > name, if it's useful geophysical data, we should come up with an appropriate > name for it. A file with standard names that don't express anything about the > scientific contents of the file may be CF compliant, but isn't the best use > of CF. > A long name is useful, but not the best way to describe data, since it's not > from > a controlled vocabulary. > > It seems to me that there should be a data variable with a standard_name that > provides the concept of 'surface melt' and has a an attribute that describes > the meanings of the different values Our existing melt terms all seem to be > more specific than what Thomas needs. > > Also, Thomas, with binary masks, the values 0 & 1 just indicate which bits > are on > or off; if the value 4001 has a specific meaning, you convert that to binary > and see > if that bit pattern matches the data record. > > Regards - Nan > > On 11/12/13 2:44 PM, Jim Biard wrote: >> Thomas, >> >> I think the sort of thing you are wanting to do is covered in a new standard >> name that I thought should have been in the latest release. Here’s the info >> about it from previous emails on the topic. >> >> status_flag >> >> A variable with the standard name of status_flag contains an indication of >> quality or other status of another data variable. The linkage between the >> data variable and the variable with the standard_name of status_flag is >> achieved using the ancillary_variables attribute. >> >> This is a dimensionless quantity (canonical units = 1). >> >> The status_flag standard name allows you to have a variable that is filled >> with status information about another variable. Notice that a variable that >> uses this standard name is assumed to be linked to another variable that >> contains some sort of measurement data (via the ancillary_variables >> attribute on the other variable). >> >> I don’t think that standard names are otherwise associated with variables >> containing only status flags. Standard names are intended (for the most >> part) to identify kinds/classes of scientific measurements. >> >> The specific meanings to associate with particular bit patterns is >> accomplished via the flag_values, flag_masks, and flag_meanings attributes >> on the variable containing the status information. >> >> And one more thing. I don’t think it's a violation of CF to have a variable >> without a standard_name attribute. If none applies, none applies. The same >> goes with units. >> >> Grace and peace, >> >> Jim >> >> >> >> >> >> On Nov 12, 2013, at 2:34 PM, Thomas Estilow <[email protected]> wrote: >> >>> Hello, >>> >>> My apologies for several messages to the list, I thought separate threads >>> would be best, as each message relates to an individual data product. >>> >>> Our team is working on a gridded product (EASE-Grid 2.0) showing daily >>> Greenland surface melt extent. We discussed possible standard names such >>> as: >>> >>> surface_snow_melt_binary_mask >>> >>> or >>> >>> surface_snow_and_ice_melt_binary_mask >>> >>> >>> Please note, the data flags we are using in each layer of the netCDF are >>> not simply 1 and 0. Any advice or recommendations on how to proceed would >>> be much appreciated. >>> >>> >>> Thank you, >>> Tom >>> >>> >>> --- >>> Thomas Estilow >>> Rutgers University Global Snow Lab >>> [email protected] >>> >>> >>> >>> >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> [email protected] >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -- > ******************************************************* > * Nan Galbraith Information Systems Specialist * > * Upper Ocean Processes Group Mail Stop 29 * > * Woods Hole Oceanographic Institution * > * Woods Hole, MA 02543 (508) 289-2444 * > ******************************************************* > > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
