So, the official request is: surface_snow_binary_mask The value is 1 where the snow cover area fraction is greater than a threshold, and 0 elsewhere. The threshold must be specified by associating a coordinate variable with the data variable and giving the coordinate variable a standard name of surface_snow_area_fraction. The values of the coordinate variable are the threshold values for the corresponding subarrays of the data variable.
Grace and peace, Jim Jim Biard Research Scholar Cooperative Institute for Climate and Satellites Remote Sensing and Applications Division National Climatic Data Center 151 Patton Ave, Asheville, NC 28801-5001 jim.bi...@noaa.gov 828-271-4900 On Sep 6, 2012, at 10:51 AM, Jonathan Gregory <j.m.greg...@reading.ac.uk> wrote: > Dear Jim and Roy > >> So, to sum up, the standard name and definition would be: >> surface_snow_cover_binary_mask: The value is 1 where the snow cover area >> fraction is greater than a threshold, and 0 elsewhere. The threshold must >> be specified by associating a scalar coordinate variable with the data >> variable and giving the scalar coordinate variable a standard name of >> surface_snow_area_fraction. The value of the scalar coordinate variable is >> the threshold value. >> >> Does that look/sound right? > > Yes, except that I think it should be surface_snow_binary_mask, for > consistency > with existing names. > > Roy subsequently suggested it should be presence_of_surface_snow. I guess that > would have the same sort of meaning. I don't think we should use that phrase > just for this case, though. There are two existing names with binary_mask and > it's in the guidelines. We could change them all if people prefer to. I would > argue that binary_mask has the advantage of indicating the data variable is 0 > and 1. Another way to convey the same info would be with a missing data mask, > and that could have a different standard name. > > If many binary_mask (or presence_of) names were requested we could no doubt > devise something more general but there doesn't seem to be a need for that > yet. > > Best wishes > > Jonathan
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
