Dear Dan
Thanks for your email. I suppose that the problem is that the data has been
quantised, whereas when considering thresholds we have continuous quantities in
mind. We didn't put "greater than or equal to" because the probability of a
continuous quantity exactly equalling the threshold is infinitesimal. A
possible solution would be to interpret "above threshold" as meaning "above or
exactly equal to the threshold". If that is a good idea, we should say it in
the definition of the quantity.
Best wishes
Jonathan
----- Forwarded message from "Hollis, Dan" <dan.hollis at metoffice.gov.uk> -----
> 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_threshold
> >
> > 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
----- End forwarded message -----
Received on Wed Sep 03 2014 - 06:57:13 BST
