Hi all, Clearly there are pros and cons of both options. However after some discussion with colleagues here we decided that we'd go with the option of requesting a new standard name. I'd therefore like to request:
number_of_days_with_lwe_thickness_of_precipitation_amount_at_or_above_threshold<javascript:void(0)> with the following definition: "Amount" means mass per unit area. The construction lwe_thickness_of_X_amount or _content means the vertical extent of a layer of liquid water having the same mass per unit area. "lwe" means liquid water equivalent. A variable whose standard name has the form number_of_days_with_X_at_or_below|above_threshold is a count of the number of days on which the condition X_at_or_below|above_threshold is satisfied. It must have a coordinate variable or scalar coordinate variable with the a standard name of X to supply the threshold(s). It must have a climatological time variable, and a cell_methods entry for within days which describes the processing of quantity X before the threshold is applied. A number_of_days is an extensive quantity in time, and the cell_methods entry for over days should be "sum". I hope that's acceptable but let me know if anyone spots any problems with this. Thanks, Dan ________________________________ From: CF-metadata [mailto:[email protected]] On Behalf Of John Graybeal Sent: 04 September 2014 17:21 To: Gregory, Jonathan Cc: CF Metadata List Subject: Re: [CF-metadata] Days of rain I don't really agree with your mathematical argument (and if that argument is valid, then the boolean attribute _doesn't_ "in effect carry part of the definition of the standard name"). But I'm fine with that approach, because users could always choose to add the boolean attribute on their own, if it makes sense to them. It doesn't have to be a part of the standard. But we would still need to add the explanatory text for what the name really means. Or, we can add the new standard names. I guess Dan's call at this point as to whether he wants to request that? John On Sep 4, 2014, at 06:03, Jonathan Gregory <[email protected]<mailto:[email protected]>> wrote: Dear Dan, John et al. I'm not comfortable with a boolean attribute that in effect carries part of the definition of the standard_name. This isn't consistent with the usual treatment of standard_names, which completely define the quantity except for those parts which are dealt with by coordinates or statistical reduction. (You could maybe argue that a boolean attribute was like a scalar coord variable supplying a reference value, as is required by some standard names, but that feels like stretching a point to me.) If we really need to distinguish .gt. from .ge. I think we should have distinct standard names for them. But I still don't think we really need to distinguish them. If the data were quantised, .gt. can include .eq. if the threshold is a multiple of the quantum; if the data were continuous, it strictly means .gt. Dan's data are anyway a mixture of quantised (for which a threshold of 0.2 mm really means 0.2 mm) and rounded (for which 0.2 mm means 0.15 mm) so it's not possible to be strict about how the threshold is applied. Best wishes Jonathan ----- Forwarded message from "Hollis, Dan" <[email protected]<mailto:[email protected]>> ----- From: "Hollis, Dan" <[email protected]<mailto:[email protected]>> To: 'John Graybeal' <[email protected]<mailto:[email protected]>>, Alison Pamment <[email protected]<mailto:[email protected]>>, CF Metadata List <[email protected]<mailto:[email protected]>>, "Gregory, Jonathan" <[email protected]<mailto:[email protected]>> Subject: RE: [CF-metadata] Days of rain Date: Thu, 4 Sep 2014 10:12:32 +0000 On balance the boolean attribute looks like the better option to me, partly for the reasons of discoverability that John highlights below, but also because it can be applied to all similar variables. Although there may only be nine 'threshold' names so far, and I would only need one more to be added, it nevertheless still seems better to choose a solution that works for all variables, both now and in the future. The boolean attribute seems to fit the bill. Regards, Dan -----Original Message----- From: John Graybeal [mailto:[email protected]] Sent: 03 September 2014 17:28 To: Alison Pamment Cc: Hollis, Dan; Gregory, Jonathan; CF Metadata List Subject: Re: [CF-metadata] Days of rain While I agree it is not a big problem to use at_or_above_threshold in this and whatever other standard names eventually are needed, discoverability would be better with the boolean attribute ("comparison_includes_equality"?). As a practical matter, people looking for, e.g., number_of_days_with_lwe_thickness_of_precipitation_amount_above_threshold data will want to discover data that is at_or_above_threshold too, but may not think (or want) to search for the additional term using at_or_above_threshold, even if they know of that possibility. That said, it's a minor point, I'm OK with either approach. I definitely think names should not rely on a particular observation technology or approach (e.g., quantization, rounding, measurement accuracy or technique). Will start a new thread re archives. john On Sep 3, 2014, at 06:52, [email protected]<mailto:[email protected]> wrote: Dear Dan, I agree that setting a threshold depending on how the data were collected does not seem very satisfactory and it wouldn't allow you to combine readings from a variety of instruments into a single data product. The definition of 'greater|less than or equal to' is clearly not the same as 'greater|less than' so I would argue that they are different quantities and should have different standard names. Currently we have only nine 'threshold' names in the table and personally I don't think it's a big problem to add one more of the form number_of_days_with_lwe_thickness_of_precipitation_amount_at_or_above_threshold. The definition would of course need to make clear the difference from the existing name and in fact the definitions should cross-reference one another to make users aware of both. Do others agree? Regarding searching the mailing list archives, if I want to find a very specific phrase within the email text I download the plain text file for the appropriate year (available from the main archive page http://mailman.cgd.ucar.edu/pipermail/cf-metadata/) and use my browser's 'Find' function. It takes a few minutes to download but it can be a useful way of pinpointing the thing you're looking for. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Email: [email protected]<mailto:[email protected]> STFC Rutherford Appleton Laboratory R25, 2.22 Harwell Oxford, Didcot, OX11 0QX, U.K. -----Original Message----- From: Hollis, Dan [mailto:[email protected]] Sent: 03 September 2014 12:55 To: Gregory, Jonathan; [email protected]<mailto:[email protected]> Subject: Re: [CF-metadata] Days of rain Hi Jonathan, For manually-read rain gauges the advice to the observer is simply to record the measurement to one decimal place. For the thresholds of interest this seems to me to be equivalent to saying the values have been rounded. Therefore 0.2 mm does mean 0.15-0.25 mm, 1.0 mm means 0.95-1.05 mm, and 10 mm means 9.95-10.05 mm. In contrast automated sites use a tipping bucket gauge (in the UK at least) which constrains the observations to be multiples of the bucket size. I believe that for all the data we use this is a nominal 0.2 mm i.e. precipitation totals can be 0.0 mm, 0.2 mm, 0.4 mm etc, and values such as 0.1 mm, 0.3 mm, 0.5 mm cannot be reported. Given that all we know is that the bucket has tipped (i.e. has become full and caused the mechanism to tip and empty the bucket) this implies that an observation of 0.2 mm actually means 0.2 <= true value < 0.4 (because the bucket has not yet tipped a second time). For our gridded climate datasets (rainfall total, days of rain etc) we use data from both types of gauge without correction or adjustment. I think we can be fairly confident that uncertainties in the interpolation process will be quite a bit larger than either the observation uncertainty or the differences between the two observation types i.e. these types of subtlety are probably 'in the noise' and to be honest not something I'd given much thought to. In conclusion I'm slightly reluctant to specify a threshold that tries to reflect how the observations have been gathered, partly because this is not the same for all sites and partly because it could change in the future (e.g. if we were to adopt a different type of rain gauge). Personally I'd prefer to describe what we do to the data once it has been collected, which in the case of the 'days of rain' variables is to test if the value is greater than or equal to a threshold. Thoughts? Regards, Dan -----Original Message----- From: CF-metadata [mailto:[email protected]] On Behalf Of Jonathan Gregory Sent: 01 September 2014 17:42 To: [email protected]<mailto:[email protected]> Subject: [CF-metadata] Days of rain Dear Dan We have several variables that we describe loosely as 'days of rain'. Strictly speaking they are a count (e.g. for a calendar month) of the number of days when the 24-hour precipitation total was greater than or equal to a threshold. We currently generate grids for three thresholds - 0.2mm, 1.0mm and 10.0mm. My intention is to use the following existing standard name: number_of_days_with_lwe_thickness_of_precipitation_amount_above_thr eshold My only slight problem is that the definition implies 'greater than' whereas our variables are 'greater than or equal to' the threshold. Assuming the observations have a precision of 0.1 mm ... I think it depends on how the data have been treated. Are they rounded to the nearest 0.1 mm? If so, a recorded value of 0.0 mm means an actual value in the range 0.00-0.05 mm, 0.1 mm means 0.05-0.15 mm, 0.2 mm means 0.15-0.25 mm, etc., and your threshold of 0.2 mm in recorded precipitation is actually a threshold of 0.15 mm. That is therefore what I would suggest as the coordinate value for the threshold. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected]<mailto:[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 -- Scanned by iCritical. _______________________________________________ CF-metadata mailing list [email protected]<mailto:[email protected]> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected]<mailto:[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
