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] 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] > 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] >> 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] >> 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] >> 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] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
