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]> 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]> ----- > >> From: "Hollis, Dan" <[email protected]> >> To: 'John Graybeal' <[email protected]>, Alison Pamment >> <[email protected]>, CF Metadata List >> <[email protected]>, "Gregory, Jonathan" >> <[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] 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 >> > > ----- End forwarded message ----- > _______________________________________________ > 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
