Dear Karl, Jonathan, Jim, thanks for those comments.
The CMIP6 variable in question is clmisr (http://clipc-services.ceda.ac.uk/dreq/u/59151ed6-9e49-11e5-803c-0d0b866b59f3.html) with a coordinatte of 16 altitude bins (http://clipc-services.ceda.ac.uk/dreq/u/dim:alt16.html ). I'd be happy with Jim's proposed solution, which does not need any change to the convention, though it may be a bit cryptic: all the examples in the convention are for cases in which all array values are intended to match one of the flag_values. Having an array which is a mixture of flags and "normal" values would be a new usage. We could, perhaps, introduce a consistency problem: ticket 151 (http://cf-trac.llnl.gov/trac/ticket/151) explains how, for variables with standard_name "area_type", flag_values and flag_meanings can be used to encode the data, in which case it is the "flag_meanings" which match the requirements of the standard name. Here, on the other hand, we want the special bin to be the exception which is not described by the standard name (altitude). So .. perhaps it is simpler to introduce a new attribute name? Concerning Jonathan and Karl's comments, the idea of calling it a "missing_value" was a mistake I made, but it actually refers to locations where cloud is detected but the height of the cloud cannot be retrieved. The current proposal is to have a value of 0.0 in the coordinate and (-99000.0,0.0) in the bounds of the special value "bin". I imagine these need to be present, but I think their values are not going to mean anything. It is certainly possible to do as Karl suggests and place an explanation in the variable description. Having the special status of the first bin explicitly flagged in way which can be easily picked up by software brings added value. regards, Martin _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
