Dear Dan Sorry to be a nuisance, but I still do not see the need for at_or_above_threshold If the data is multiples of some unit (like yours is), a value might exactly equal the threshold. If it isn't discretised (like model data usually isn't, except by the precision of floating-point numbers), the value is very unlikely to equal the threshold exactly. Would it not be OK to understand the existing phrase "above_threshold" as meaning "at_or_above_threshold"? It seems redundant to have both in the standard_name table, because I don't think anyone would use the distinction between the two to label two quantities as being different.
If it's confusing to interpret "above_threshold" as "at_or_above_threshold" then let's rename all the affected standard_names to say "at_or_above|below". But that is cumbersome. Though we try to avoid abbreviations in general in the standard name table, maybe we could use _geq_ and _leq_ in this case. However, I don't think it would be bad just to tweak the definition of "above". Cheers Jonathan ----- Forwarded message from "Hollis, Dan" <dan.hol...@metoffice.gov.uk> ----- > From: "Hollis, Dan" <dan.hol...@metoffice.gov.uk> > To: CF Metadata List <cf-metadata@cgd.ucar.edu> > CC: 'John Graybeal' <john.grayb...@marinexplore.com>, "Gregory, Jonathan" > <j.m.greg...@reading.ac.uk> > Subject: RE: [CF-metadata] Days of rain > Date: Thu, 18 Sep 2014 14:19:06 +0000 > > 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:cf-metadata-boun...@cgd.ucar.edu] 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 > <j.m.greg...@reading.ac.uk<mailto:j.m.greg...@reading.ac.uk>> 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" > <dan.hol...@metoffice.gov.uk<mailto:dan.hol...@metoffice.gov.uk>> ----- > > From: "Hollis, Dan" > <dan.hol...@metoffice.gov.uk<mailto:dan.hol...@metoffice.gov.uk>> > To: 'John Graybeal' > <john.grayb...@marinexplore.com<mailto:john.grayb...@marinexplore.com>>, > Alison Pamment > <alison.pamm...@stfc.ac.uk<mailto:alison.pamm...@stfc.ac.uk>>, CF Metadata > List > <cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>>, "Gregory, > Jonathan" > <j.m.greg...@reading.ac.uk<mailto:j.m.greg...@reading.ac.uk>> > 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:john.grayb...@marinexplore.com] > 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, > alison.pamm...@stfc.ac.uk<mailto:alison.pamm...@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.pamm...@stfc.ac.uk<mailto:alison.pamm...@stfc.ac.uk> > STFC Rutherford Appleton Laboratory > R25, 2.22 > Harwell Oxford, Didcot, OX11 0QX, U.K. > > > > -----Original Message----- > From: Hollis, Dan [mailto:dan.hol...@metoffice.gov.uk] > Sent: 03 September 2014 12:55 > To: Gregory, Jonathan; > cf-metadata@cgd.ucar.edu<mailto:cf-metadata@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-boun...@cgd.ucar.edu] On Behalf > Of Jonathan Gregory > Sent: 01 September 2014 17:42 > To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@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@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- > Scanned by iCritical. > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
