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, alison.pamment at stfc.ac.uk 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: alison.pamment at stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
>
>
>> -----Original Message-----
>> From: Hollis, Dan [mailto:dan.hollis at metoffice.gov.uk]
>> Sent: 03 September 2014 12:55
>> To: Gregory, Jonathan; cf-metadata at cgd.ucar.edu
>> 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:cf-metadata-bounces at cgd.ucar.edu] On Behalf
>> Of Jonathan Gregory
>> Sent: 01 September 2014 17:42
>> To: cf-metadata at cgd.ucar.edu
>> 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
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> --
> Scanned by iCritical.
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Sep 03 2014 - 10:27:42 BST
