Dear Martin Thanks for explaining the use case. I agree that where flag_meanings is used to encode a string-valued data variable, the permissible flag_values are those which are allowed by data variable's standard name, if they are standardised. I also agree that we should give guidance for the use of flag_values with coordinate variables. I suggest something more general, such that coordinate values which are flag_values are status codes that indicate that a numerical coordinate value cannot be assigned to the cell, but the data is nonetheless meaningful (in some way indicated by flag_meanings). For example (as I said before) a possible application is for all coordinate values which are too small or too large.
Best wishes Jonathan ----- Forwarded message from Martin Juckes - UKRI STFC <[email protected]> ----- > Date: Thu, 16 May 2019 08:55:22 +0000 > From: Martin Juckes - UKRI STFC <[email protected]> > To: Jonathan Gregory <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [CF-metadata] Missing data bins in histograms > > Dear Jonathan, > > > OK, flagged-dimension-array approach is certainly a more compact > representation than my previous proposal (which had a flagged auxillary > coordinate). It would certainly be an extension to the scope of the examples > in the CF Conventions document. I have a slight concern that there might be a > subtle conflict in terms of the way in which the "flag_meanings" are > interpreted -- but I think that can be dealt with if we frame the description > of new example carefully. > > > Firstly, it is perhaps relevant to clear up that "out_of_range" would not > work in this case. The data in this bin is, I believe, a count of the > profiles taken by the sensor for which the retrieval algorithm returned an > error code rather than a height value. It is common practise to want an > "out_of_range" bin in a histogram, but that is not the use case here. If we > were recording the results from individual retrievals in a field with > standard name "height", these data points would be flagged using the > "missing_value" attribute. > > > In the existing examples of "flag_meanings" it appears that the status codes > used are application specific, so there is perhaps no need to make a firm > decision on the text used here ... though the example should make sense. > > > There are standard names which assert specific rules about the usage of > "flag_meanings" -- we have discussed these in trac ticket > 153<https://cf-trac.llnl.gov/trac/ticket/153>. That discussion is not > concluded, but the clear intention is that, for some names at least, the flag > values/meanings mechanism should be used with "flag_meanings" which conform > to the specification of the standard name. For example, if the standard name > is "region", the "flag_meanings" values should come from the accepted list of > region names. > > > In general, I think the "flag_meanings" should be consistent with the > standard name. Perhaps we could express this as "The flag_meanings values > should be consistent with the specifications of the standard name or, > alternatively, when used in a coordinate array, represent status codes > associated with data which would be reported as missing." With a > clarification of this kind, I think the approach you are suggesting can work. > This makes it clear that we are dealing with data points which would use the > "missing_value" when recorded in a data array, but we have a different > approach here because we are constructing a coordinate array to label data > values, and the coordinate array has a label for missing values, not an > missing value. > > > regards, > > Martin > > > > > ________________________________ > From: CF-metadata <[email protected]> on behalf of Jonathan > Gregory <[email protected]> > Sent: 15 May 2019 16:48 > To: [email protected] > Subject: Re: [CF-metadata] Missing data bins in histograms > > Dear Martin > > Yes, that's what I meant, thanks. Indeed, I might be suggesting an extension > of the use of flag_values, because you're right that its existing uses are in > cases where every data value that occurs is one which appears in flag_values. > However this is not a requirement in the convention or conformance documents. > > In your particular case, it is best to give the meaning as "missing"? It would > be more informative to call them "out of range", perhaps. > > Best wishes > > Jonathan > > ----- Forwarded message from Martin Juckes - UKRI STFC > <[email protected]> ----- > > > Date: Tue, 14 May 2019 14:34:48 +0000 > > From: Martin Juckes - UKRI STFC <[email protected]> > > To: Jonathan Gregory <[email protected]>, "[email protected]" > > <[email protected]> > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > Dear Jonathan, > > > > > > Sorry, I think I misunderstood the scope of valid usage of "flag_values". > > I've only seen it used in contexts in which all values of the flagged array > > are translated using the "flag_values"/"flag_meanings" pairs, but you are > > suggesting, I think, that it should only apply to the one anomalous bin. If > > we can use a single "flag_values" without changing the interpretation of > > the rest of the array, that would make the solution easier. > > > > > > Does this correspond to what you are thinking of: > > > > > > float data(time,lat,lon,zbins); > > data: standard_name = > > "histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid"; > > data: coordinates="status"; > > float zbins(zbins); > > zbins: long_name="Height ranges (with bin for missing data at first > > element)" > > zbins: units="m"; > > zbins: bounds="zbin_bnds"; > > zbins: standard_name = "height"; > > > > zbins:flag_values = -9999.f; > > zbins:flag_meanings = "missing_values"; > > float zbin_bnds(zindex,2); > > character status(char_len); > > status:standard_name = "status_flag"; > > status:long_name = "Flag indicating quality of histogram"; > > float lat(lat); > > float lon(lon); > > > > data: > > zbins = -9999., 25., 100., ....; > > zbin_bnds = -9999.,0., 0., 50., 50., 150., ... > > > > regards, > > Martin > > ________________________________ > > From: CF-metadata <[email protected]> on behalf of Jonathan > > Gregory <[email protected]> > > Sent: 14 May 2019 13:43 > > To: [email protected] > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > Dear Martin > > > > I agree that if valid_range implies masked-out data in some software, we > > can't > > put special values out of the range, and that we shouldn't tamper with > > missing > > data. I still think that flag_values is a better way to indicate special > > values in a coordinate variable than an auxiliary coordinate variable would > > be. > > If there are flag values, by definition those values aren't physical > > coordinate > > values, and the user of such data need to be aware of that. That would be > > the > > consequence of changing the convention to allow flag_values for coordinate > > variables, just as it is presently the case that a user of a data variable > > ought to check whether it has flag_values, which would likewise indicate > > that > > some of the valid values are not actually physical values. However I don't > > think we ought to change the standard_name to signal it, since introducing > > new > > standard_names requires software to recognise both versions. > > > > Best wishes > > > > Jonathan > > > > ----- Forwarded message from Martin Juckes - UKRI STFC > > <[email protected]> ----- > > > > > Date: Tue, 14 May 2019 09:03:19 +0000 > > > From: Martin Juckes - UKRI STFC <[email protected]> > > > To: Jonathan Gregory <[email protected]>, > > > "[email protected]" > > > <[email protected]> > > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > > > Dear Jonathan, > > > > > > > > > I looked at "valid_range", and also "actual_range", but I believe that > > > the definitions of either of these would have to be changed to > > > accommodate this usage, and we would run into the problem that Jim raised > > > in connection with my earlier suggestion of using "missing_value": such > > > changes can break assumptions made by existing software. Data outside the > > > "valid_range" may well be automatically rejected by a user application > > > before the data gets to any CF aware libraries. For instance, python > > > netCDF4 at version 1.3.0 and 1.3.1 automatically removes data outside the > > > valid_range, giving the user a masked array. There is some discussion of > > > this here: https://github.com/Unidata/netcdf4-python/issues/748. > > > > > > > > > <https://github.com/Unidata/netcdf4-python/issues/748>It is possible to > > > circumvent this behaviour by changing the auto-masking setting in python > > > netCDF4, and the NUG does suggest using values outside the "valid_range" > > > as flags. NUG also suggests using the missing_value attribute to list > > > such flag values ... but Jim has pointed out that such an approach is > > > likely to cause problems with many applications. This is a complex area > > > because the meaning of "missing_value" in NUG has evolved. Up until CF > > > 1.5 it appears that a "missing_value" meant, unambiguously, missing data. > > > The current CF appears to changed this in line with NUG so that > > > different usages are now permissible, but I still agree with Jim's > > > objection. We can't, I'm sure, at this stage, follow an approach which > > > depends on users being able to control the auto-masking settings (it is a > > > simple call to the "set_auto_mask" method if you are using the python > > > netCDF4 library directly ... but may not be available to users who are > > > working with applications built on the library). > > > > > > > > > I wanted to use a new standard name for the hight bins because of the > > > fact that the value in the first bin, which I have set to -9999., is not > > > a height. This data point needs to have a valid floating point value to > > > conform to the rules for a coordinate array, but, unlike the rest of the > > > array, it should not be interpreted as height. This is signalled by the > > > presence of an auxiliary coordinate -- but I'm not sure that that is > > > adequate. Applications and users are entitled to believe that a variable > > > which has standard name "height" really refers to height, without having > > > to check all the auxiliary coordinates to see if there is something there > > > which modifies the meaning of the variable. The standard name > > > "height_bins" would signal that they must look in the auxiliary > > > coordinate. > > > > > > > > > Do you agree with the necessity and appropriateness of the new name of > > > "bin_status_flag" which I have suggested for the auxiliary coordinate? > > > > > > > > > regards, > > > > > > Martin > > > > > > ________________________________ > > > From: CF-metadata <[email protected]> on behalf of > > > Jonathan Gregory <[email protected]> > > > Sent: 13 May 2019 18:00 > > > To: [email protected] > > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > > > Dear Martin > > > > > > I agree that an alternative which would not require a change to the > > > convention is to attach a string-valued aux coord variable. However, the > > > flags are much more economical and seem natural, as you say. > > > > > > As I said in my last email, I feel that it's better to keep the standard > > > name > > > as it is, despite the presence of a special value in it which isn't > > > really a > > > coordinate value. Maybe a valid_range could be specified, with the special > > > value outside the range? I'm not sure if that would count as an error, > > > but it > > > is not the same as reinterpreting missing data, which would be > > > problematic. > > > > > > Best wishes > > > > > > Jonathan > > > > > > ----- Forwarded message from Martin Juckes - UKRI STFC > > > <[email protected]> ----- > > > > > > > Date: Mon, 13 May 2019 09:39:11 +0000 > > > > From: Martin Juckes - UKRI STFC <[email protected]> > > > > To: Jim Biard <[email protected]>, "[email protected]" > > > > <[email protected]> > > > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > > > > > Dear Jim, Jonathan, > > > > > > > > > > > > OK, I accept your point that this would be a new meaning of > > > > "missing_value", and that probably causes more serious problems than > > > > the one we are trying to solve. > > > > > > > > > > > > I believe that Jonathan is also correct in saying that we can't use > > > > flag_values for this purpose without a change in the convention ... but > > > > perhaps we should explore whether such a change would lead to a good > > > > solution. Do you have a specific proposal in mind? > > > > > > > > > > > > If not, here is an idea adapted from my last post. In this example I > > > > have used a real valued dimension coordinate to define the data bins, > > > > with an arbitrary value in the first bin. The new feature is an > > > > auxiliary coordinate which is constructed to label the first bin as > > > > "missing_data" and the remaining bins as "data". > > > > > > > > > > > > I believe that it would be mis-leading to use the existing standard > > > > name "height" for the variable "zbins" in this example, because the > > > > first bin is not a height range. Hence, I suggest introducing a new > > > > standard name "height_bins" which would allow one or more bins to have > > > > special meanings which should be indicated by a string valued auxiliary > > > > coordinate. > > > > > > > > > > > > "zbin_flags" could also be encoded as a character array, with values > > > > ["missing_values", "data", "data", ......]. This could be done without > > > > changing the convention text, since character arrays are allowed > > > > auxiliary coordinate. However, I believe that it would be worth making > > > > an adjustment here, since the use of flags seems more natural. > > > > > > > > > > > > I've given the "zbin_flags" a new standard name "bin_status_flag", > > > > which is related to the existing term "status_flag", but refers to the > > > > status of the data being counted in the histogram rather than to the > > > > status of the histogram itself. This allows us to refer unambiguously > > > > to the fact that we are counting missing data in the first bin. > > > > > > > > > > > > Would this work? > > > > > > > > > > > > float data(time,lat,lon,zbins); > > > > > > > > data: standard_name = > > > > "histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid"; > > > > > > > > data: coordinates="zbin_flags status"; > > > > > > > > float zbins(zbina); > > > > > > > > zbins: long_name="Height ranges (with bin for missing data at first > > > > element)" > > > > > > > > zbins: units="m"; > > > > > > > > zbins: bounds="zbin_bnds"; > > > > > > > > zbins: standard_name = "height_bins"; > > > > > > > > float zbin_bnds(zindex,2); > > > > > > > > integer zbin_flags(zbins); > > > > > > > > zbin_flags: long_name = "Flags indicating the status of data which > > > > is counted in each bin"; > > > > > > > > zbin_flags:standard_name = "bin_status_flag"; > > > > > > > > zbin_flags:flag_values = 0,1; > > > > > > > > zbin_flags:flag_meanings = "missing_values data"; > > > > > > > > character status(char_len); > > > > > > > > status:standard_name = "status_flag"; > > > > > > > > status:long_name = "Flag indicating quality of histogram"; > > > > > > > > float lat(lat); > > > > > > > > float lon(lon); > > > > > > > > > > > > data: > > > > > > > > zbins = -9999., 25., 100., ....; > > > > > > > > zbin_bnds = -9999.,0., 0., 50., 50., 150., ... > > > > > > > > zbin_flags = 0,1,1,1,... > > > > > > > > > > > > Regards, > > > > Martin > > > > > > > > ________________________________ > > > > From: CF-metadata <[email protected]> on behalf of Jim > > > > Biard <[email protected]> > > > > Sent: 10 May 2019 15:58 > > > > To: [email protected] > > > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > > > > > > > > > Hi. > > > > > > > > Sorry I have been so quiet lately. I've been caught up in other > > > > activities. > > > > > > > > I have a strong aversion to the proposal to overload the missing_value > > > > attribute with a wholly different meaning. Using missing_value in this > > > > way will produce unexpected results in a number of existing software > > > > packages. If the minor modification to CF to designate flag attributes > > > > to be used on coordinate variables doesn't seem like an acceptable > > > > solution for one reason or another, I think we should define a new > > > > convention that doesn't add contradictory interpretations of existing > > > > attributes. > > > > > > > > Grace and peace, > > > > > > > > Jim > > > > > > > > On 5/2/19 11:49 AM, Martin Juckes - UKRI STFC wrote: > > > > > > > > Dear Jonathan, Jim, > > > > > > > > > > > > > > > > I’m sorry to have dropped this conversation after starting it three > > > > years ago. We ended up not fixing the problem for CMIP6, but I think it > > > > is worth taking another look. > > > > > > > > > > > > > > > > Coming back to it again, I think that a variation on Jim’s suggestion > > > > could work: rather than using flags it should be possible to use a > > > > coordinate variable, as is done for some CMIP variables that have > > > > region names along one axis. The NetCDF dimension would be an index, > > > > and the array of values defining the bins would be an auxiliary > > > > coordinate which, I believe, is not subject to the rules on > > > > monotonicity and missing values which apply to NetCDF dimensions. There > > > > may be a need for some clarifications, but I think this approach would > > > > be much closer to the current convention that any change in the > > > > specification for non-auxiliary coordinate variables. > > > > > > > > > > > > We have a specific use case in CMIP6 for which the bins are height bins > > > > (height of detected cloud), with one bin reserved for "retrieval error". > > > > > > > > > > > > This might not need a change in the convention rules, but it would > > > > help, I think, to at least add an example and a standard name for the > > > > coordinate variable. For example: > > > > > > > > > > > > float data(time,lat,lon,zindex); > > > > > > > > data: standard_name = > > > > "histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid"; > > > > > > > > data: coordinates="zbins"; > > > > > > > > float zbins(zindex); > > > > > > > > zbins: long_name="Height ranges (with bin for missing data at first > > > > element)"; > > > > > > > > zbins:missing_value= -9999.; > > > > > > > > zbins: units="m"; > > > > > > > > zbins: bounds="zbin_bnds"; > > > > > > > > zbins: standard_name = "????"; > > > > > > > > float zbin_bnds(zindex,2); > > > > > > > > zbin_bnds:missing_value= -9999.; > > > > > > > > float lat(lat); > > > > > > > > float lon(lon); > > > > > > > > > > > > data: > > > > > > > > zbins = -9999., 25., 100., ....; > > > > > > > > zbin_bnds = -9999.,-9999., 0., 50., 50., 150., ... > > > > > > > > > > > > The use of missing_value in the bounds variable appears to conflict > > > > with conformance rules, but I'm not sure if this is really banned by > > > > the convention in this context. > > > > > > > > > > > > Using missing_value in this way appears to be acceptable to the > > > > convention, but I think it conflicts with the spirit of the convention: > > > > it is not indicating that a value of "zbins" is missing, but indicating > > > > that this index of the array relates to a count of missing values. For > > > > this reason I have omitted _FillValue. > > > > > > > > > > > > The "zbins" auxiliary coordinate here is a height-like variable, but I > > > > don't think we can use a standard name "height": is it worth adding a > > > > standard name "height_bins" defined to be "Height ranges, as used, for > > > > example in a histogram or frequency distribution. A variable with this > > > > standard name may include a special bin for the count or frequency of > > > > missing data. This should be indicated by setting the value of that bin > > > > and its bounds to equal the missing_value of the variable. If there is > > > > no missing value bin, it is recommended that the term 'height' be used > > > > instead." > > > > > > > > > > > > regards, > > > > > > > > Martin > > > > > > > > > > > > CF-metadata] Missing data bins in histograms > > > > > > > > Jonathan Gregoryj.m.gregory at reading.ac.uk > > > > <mailto:cf-metadata%40cgd.ucar.edu?Subject=Re%3A%20%5BCF-metadata%5D%20Missing%20data%20bins%20in%20histograms&In-Reply-To=%3C20161013094247.GF6219%40met.reading.ac.uk%3E><mailto:cf-metadata%40cgd.ucar.edu?Subject=Re%3A%20%5BCF-metadata%5D%20Missing%20data%20bins%20in%20histograms&In-Reply-To=%3C20161013094247.GF6219%40met.reading.ac.uk%3E> > > > > Thu Oct 13 03:42:47 MDT 2016 > > > > > > > > * Previous message (by thread): [CF-metadata] Missing data bins in > > > > histograms > > > > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/018983.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/018983.html> > > > > * Next message (by thread): [CF-metadata] Usage of > > > > histogram_of_X_over_Z > > > > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/008836.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/008836.html> > > > > * Messages sorted by: [ date > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984> > > > > [ thread > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984> > > > > [ subject > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984> > > > > [ author > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984> > > > > > > > > ________________________________ > > > > > > > > Dear Jim > > > > > > > > > > > > > > > > In Appendix A it does not say that the flag attributes are allowed for > > > > > > > > coordinate variables - it has just "D" in the "Use" column. This is not > > > > an > > > > > > > > argument why they shouldn't be if there is a need, but they weren't > > > > introduced > > > > > > > > with that in mind. The use which you suggested for Martin's case is a > > > > good > > > > > > > > idea, but I think it would need a change to the convention. > > > > > > > > > > > > > > > > Best wishes > > > > > > > > > > > > > > > > Jonathan > > > > > > > > > > > > > > > > ----- Forwarded message from Jim Biard <jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> > > > > ----- > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 12 Oct 2016 14:58:11 -0400 > > > > > > > > > > > > From: Jim Biard <jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> > > > > > > > > > > > > To: cf-metadata at > > > > cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > > > > > > > > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > > > > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) > > > > > > > > > > > > Gecko/20100101 Thunderbird/45.4.0 > > > > > > > > > > > > Jonathan, > > > > > > > > > > > > Missing/fill values are not allowed, but I don't see any language > > > > > > > > > > > > prohibiting flags. I'd appreciate it if you could expand on your > > > > > > > > > > > > thoughts about why they aren't allowed. > > > > > > > > > > > > Grace and peace, > > > > > > > > > > > > Jim > > > > > > > > > > > > On 10/12/16 1:30 PM, Jonathan Gregory wrote: > > > > > > > > > > > > Dear Jim > > > > > > > > > > > > That is an ingenious idea. I don't think the flag atts are currently > > > > allowed > > > > > > > > > > > > for coord variables, but they could be, I agree. > > > > > > > > > > > > Best wishes > > > > > > > > > > > > Jonathan > > > > > > > > > > > > ----- Forwarded message from Jim Biard <jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> > > > > ----- > > > > > > > > > > > > Date: Tue, 11 Oct 2016 14:39:56 -0400 > > > > > > > > > > > > From: Jim Biard <jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> > > > > > > > > > > > > To: cf-metadata at > > > > cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > > > > > > > > > Subject: Re: [CF-metadata] Missing data bins in histograms > > > > > > > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) > > > > > > > > > > > > Gecko/20100101 Thunderbird/45.4.0 > > > > > > > > > > > > Hi. > > > > > > > > > > > > Another approach could be to use flag_values and flag_meanings on > > > > > > > > > > > > the coordinate variable to indicate one or more special coordinate > > > > > > > > > > > > values that correspond to any number of "missing data" or "out of > > > > > > > > > > > > bounds" bins. These attributes aren't forbidden by CF, and > > > > > > > > > > > > everything should be fine as long as the coordinate variable remains > > > > > > > > > > > > monotonic. > > > > > > > > > > > > Grace and peace, > > > > > > > > > > > > Jim > > > > > > > > > > > > On 10/11/16 8:41 AM, martin.juckes at > > > > stfc.ac.uk<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > the CF standard name list has two "histogram_.... " entries, and in the > > > > CMIP6 data request we may need to add a third, a > > > > histogram_of_cloud_top_height. Besides the standard name, we also need, > > > > for this new variable, a method of encoding the "missing data" bin in > > > > the histogram. That is, the histogram should record frequency in 16 > > > > data bins and one additional bin for the frequency of missing data. > > > > > > > > > > > > Can we define a "missing_data_index" attribute for histogram variables, > > > > and use this to indicate that the first bin in the array has this > > > > special purpose. It might be more pythonic to put the _FillValue in the > > > > coordinate value for the missing data bin, but I suspect that this > > > > would cause substantial problems for many software packages. > > > > > > > > > > > > regards, > > > > > > > > > > > > Martin > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > CF-metadata mailing list > > > > > > > > > > > > CF-metadata at > > > > cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > > > > > > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > > > > > > -- > > > > > > > > > > > > CICS-NC <http://www.cicsnc.org/><http://www.cicsnc.org/> Visit us on > > > > > > > > > > > > Facebook > > > > <http://www.facebook.com/cicsnc><http://www.facebook.com/cicsnc> > > > > *Jim Biard* > > > > > > > > > > > > *Research Scholar* > > > > > > > > > > > > Cooperative Institute for Climate and Satellites NC > > > > <http://cicsnc.org/><http://cicsnc.org/> > > > > > > > > > > > > North Carolina State University <http://ncsu.edu/><http://ncsu.edu/> > > > > > > > > > > > > NOAA National Centers for Environmental Information > > > > <http://ncdc.noaa.gov/><http://ncdc.noaa.gov/> > > > > > > > > > > > > /formerly NOAA’s National Climatic Data Center/ > > > > > > > > > > > > 151 Patton Ave, Asheville, NC 28801 > > > > > > > > > > > > e: jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > <mailto:jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> > > > > > > > > > > > > o: +1 828 271 4900 > > > > > > > > > > > > /Connect with us on Facebook for climate > > > > > > > > > > > > <https://www.facebook.com/NOAANCEIclimate><https://www.facebook.com/NOAANCEIclimate> > > > > and ocean and geophysics > > > > > > > > > > > > <https://www.facebook.com/NOAANCEIoceangeo><https://www.facebook.com/NOAANCEIoceangeo> > > > > information, and follow > > > > > > > > > > > > us on Twitter at @NOAANCEIclimate > > > > > > > > > > > > <https://twitter.com/NOAANCEIclimate><https://twitter.com/NOAANCEIclimate> > > > > and @NOAANCEIocngeo > > > > > > > > > > > > <https://twitter.com/NOAANCEIocngeo><https://twitter.com/NOAANCEIocngeo>. > > > > / > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > CF-metadata mailing list > > > > > > > > > > > > CF-metadata at > > > > cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > > > > > > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > > > > > > ----- End forwarded message ----- > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > CF-metadata mailing list > > > > > > > > > > > > CF-metadata at > > > > cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > > > > > > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > > > > > > -- > > > > > > > > > > > > CICS-NC <http://www.cicsnc.org/><http://www.cicsnc.org/> Visit us on > > > > > > > > > > > > Facebook > > > > <http://www.facebook.com/cicsnc><http://www.facebook.com/cicsnc> *Jim > > > > Biard* > > > > > > > > > > > > *Research Scholar* > > > > > > > > > > > > Cooperative Institute for Climate and Satellites NC > > > > <http://cicsnc.org/><http://cicsnc.org/> > > > > > > > > > > > > North Carolina State University <http://ncsu.edu/><http://ncsu.edu/> > > > > > > > > > > > > NOAA National Centers for Environmental Information > > > > <http://ncdc.noaa.gov/><http://ncdc.noaa.gov/> > > > > > > > > > > > > /formerly NOAA’s National Climatic Data Center/ > > > > > > > > > > > > 151 Patton Ave, Asheville, NC 28801 > > > > > > > > > > > > e: jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > <mailto:jbiard at > > > > cicsnc.org<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>> > > > > > > > > > > > > o: +1 828 271 4900 > > > > > > > > > > > > /Connect with us on Facebook for climate > > > > > > > > > > > > <https://www.facebook.com/NOAANCEIclimate><https://www.facebook.com/NOAANCEIclimate> > > > > and ocean and geophysics > > > > > > > > > > > > <https://www.facebook.com/NOAANCEIoceangeo><https://www.facebook.com/NOAANCEIoceangeo> > > > > information, and follow > > > > > > > > > > > > us on Twitter at @NOAANCEIclimate > > > > > > > > > > > > <https://twitter.com/NOAANCEIclimate><https://twitter.com/NOAANCEIclimate> > > > > and @NOAANCEIocngeo > > > > > > > > > > > > <https://twitter.com/NOAANCEIocngeo><https://twitter.com/NOAANCEIocngeo>. > > > > / > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > CF-metadata mailing list > > > > > > > > > > > > CF-metadata at > > > > cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > > > > > > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > > > > > > ----- End forwarded message ----- > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > * Previous message (by thread): [CF-metadata] Missing data bins in > > > > histograms > > > > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/018983.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/018983.html> > > > > * Next message (by thread): [CF-metadata] Usage of > > > > histogram_of_X_over_Z > > > > <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/008836.html><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/008836.html> > > > > * Messages sorted by: [ date > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/date.html#18984> > > > > [ thread > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/thread.html#18984> > > > > [ subject > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/subject.html#18984> > > > > [ author > > > > ]<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984><http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/author.html#18984> > > > > > > > > ________________________________ > > > > > > > > More information about the CF-metadata mailing > > > > list<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata> > > > > > > > > > > > > -- > > > > [CICS-NC] <http://www.cicsnc.org/> Visit us on > > > > Facebook <http://www.facebook.com/cicsnc> Jim Biard > > > > Research Scholar > > > > Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> > > > > North Carolina State University <http://ncsu.edu/> > > > > NOAA National Centers for Environmental Information > > > > <http://ncdc.noaa.gov/> > > > > formerly NOAA’s National Climatic Data Center > > > > 151 Patton Ave, Asheville, NC 28801 > > > > e: [email protected]<mailto:[email protected]> > > > > o: +1 828 271 4900 > > > > > > > > Connect with us on Facebook for > > > > climate<https://www.facebook.com/NOAANCEIclimate> and ocean and > > > > geophysics<https://www.facebook.com/NOAANCEIoceangeo> information, and > > > > follow us on Twitter at > > > > @NOAANCEIclimate<https://twitter.com/NOAANCEIclimate> and > > > > @NOAANCEIocngeo<https://twitter.com/NOAANCEIocngeo>. > > > > > > > > _______________________________________________ > > > > CF-metadata mailing list > > > > [email protected] > > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > ----- End forwarded message ----- > > > _______________________________________________ > > > CF-metadata mailing list > > > [email protected] > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > ----- End forwarded message ----- > > _______________________________________________ > > CF-metadata mailing list > > [email protected] > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
