Both these questions are about the boilerplate text, everything else seemed fine to me.
In the sentence below, there is a typo "the a". > It must have a coordinate variable or scalar coordinate variable with the a > standard name of X to supply the threshold(s). And in use, do I understand correctly that a coordinate variable (presumably dimension 1?) with standard name X (in this case, lwe_thickness_of_precipitation_amount) conveys the idea of the threshold value? So setting lwe_thickness_of_precipition_amount to 2 cm means the overall variable has a threshold of 2 cm? (It just seems like a _threshold at the end would be much clearer, so I'm just making sure I understand.) John On Sep 18, 2014, at 07:19, Hollis, Dan <dan.hol...@metoffice.gov.uk> wrote: > 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 > > 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> 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> >> ----- >> >>> From: "Hollis, Dan" <dan.hol...@metoffice.gov.uk> >>> To: 'John Graybeal' <john.grayb...@marinexplore.com>, Alison Pamment >>> <alison.pamm...@stfc.ac.uk>, CF Metadata List >>> <cf-metadata@cgd.ucar.edu>, "Gregory, Jonathan" >>> <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 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 >>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>> 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 > > _______________________________________________ > CF-metadata mailing list > 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
