Dear Greg
I agree that flag values are quite often generated in the way you describe,
by logical OR of bit values. While this could be described using the current
convention, by enumerating the translation for all the possible distinct ORed
combinations, that would obviously be very inefficient! I would suggest that
rather than introduce an alternative to "flag", we could modify it, thus:
byte precip_qc(time, z0, y0, x0) ;
precip_qc:long_name = "Precipitation status bit field" ;
precip_qc:grid_mapping = "grid_mapping0" ;
precip_qc:_FillValue = 0b ;
precip_qc:valid_range = 1b, 15b ;
precip_qc:flag_masks = 1b, 2b, 4b, 8b ;
precip_qc:flag_meanings = "no_coverage impaired phase_mixed phase_snow";
where the use of flag_masks instead of flag_values implies that the values
can be ORed, rather than being mutually exclusive. What do you think?
I also wonder whether a more general treatment would be helpful, because a flag
value could be a logical OR of codes which may occupy more than one bit e.g.
a flag might be defined as an OR of bits 0-1 (with four possible values),
bit 2 (with two) and bit 3-5 (with eight). Is that likely to be useful? It is
a combination of the two approaches.
To propose a change to the convention, you start a new ticket on the CF trac
website under
http://cf-pcmdi.llnl.gov/, using the template provided. The
proposal should say exactly what text should be changed (as you did) and also
what changes are needed to the conformance document.
Best wishes
Jonathan
Received on Fri Mar 21 2008 - 02:08:14 GMT
