Jim, Thanks so much for the clarification. Our team was under the impression that standard names were required for CF compliance. I should have read the conventions more closely.
It seems that for the time being, long names will suffice. Kind regards, Tom --- Thomas Estilow Rutgers University Global Snow Lab [email protected] On Nov 12, 2013, at 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 > > 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 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
