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.hollis at 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-bounces at 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.gregory at 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.hollis at metoffice.gov.uk> -----
>>
>>> From: "Hollis, Dan" <dan.hollis at metoffice.gov.uk>
>>> To: 'John Graybeal' <john.graybeal at marinexplore.com>, Alison Pamment
>>> <alison.pamment at stfc.ac.uk>, CF Metadata List
>>> <cf-metadata at cgd.ucar.edu>, "Gregory, Jonathan"
>>> <j.m.gregory at 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.graybeal at 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.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
>>>
>>
>> ----- End forwarded message -----
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140918/cd190ba4/attachment-0001.html>
Received on Thu Sep 18 2014 - 09:27:53 BST
