# [CF-metadata] Overlapping time_bounds (running mean data)

Jim Biard jbiard at cicsnc.org
Fri Mar 13 06:59:00 MDT 2015

```David,

I was using upper and lower in a notional sense, and you are right that
coordinates can be monotonically increasing or decreasing. To be
completely general, I guess I would need to refer to first and second
bounds. So the first bound of cell j is inclusive and the second bound
of cell j is exclusive, with the understanding that the first and second
bounds for each cell must increase or decrease in the same way as the
coordinate values.

This "asymmetrical interpretation" is quite common. The point is, if two
bounds values refer to the same point, and if you don't want to overlap
the cells, then one of the bounds must be exclusive. You could go with
an interpretation that the first bound is exclusive, but that runs
counter to most natural interpretations. As an example, let's say I have
cells with centers at 1.5, 2.5, and 3.5, and boundaries at 1.0, 2.0,
3.0, and 4.0.

Cell Num
Center
First Bound
Second Bound
1
1.5
1.0
2.0
2
2.5
2.0
3.0
3
3.5
3.0
4.0

If I have a data point that has a coordinate value of 1.0, which cell
does it belong to? The CF conventions would indicate that the answer is
cell 1, thus the first bound is inclusive. If I have a data point that
has a coordinate value of 3.0, which cell does it belong to? If the
second bound is inclusive, then the data point belongs to both cell 2
and cell 3. If the second bound is exclusive, then the data point
unambiguously belongs to cell 3. If the second bound is inclusive, then
you would need to make the bound value infinitesimally smaller than the
first bound for the next cell in order to keep the bounds from overlapping.

Grace and peace,

Jim

On 3/13/15 6:44 AM, David Hassell wrote:
> Hi Jim,
>
>> Section 7.1 of the CF Conventions doesn't say it directly, but it
>> does state that contiguous cell boundaries are described by the
>> upper bound of one cell being equal to the lower bound of the next
>> cell. This implies that the upper bound is exclusive.
> I'm not sure about this asymmetrical imterpretation. On the other
> hand, why doesn't it imply that the lower bound of the next cell is
> inclusive, given that they are identical?
>
> The conventions doesn't mention the words "upper" or "lower" in
> relation to bounds, presumably because they may be increasing or
> decreasing and so the larger bound may be on the "left" or the "right"
> of the cell, so I don't think it is right to assume a preference;
> especially when bounds are generalised to 2+ dimensions.
>
> All the best,
>
> David
>
> ---- Original message from Jim Biard (01PM 12 Mar 15)
>
>> Date: Thu, 12 Mar 2015 13:26:23 -0400
>> From: Jim Biard <jbiard at cicsnc.org>
>> CC: cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] Overlapping time_bounds (running mean data)
>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
>>   Gecko/20100101 Thunderbird/31.5.0
>>
>> David,
>>
>> The idea of exclusive vs inclusive bounds is that an inclusive bound
>> is a 'less than or equal to' or 'greater than or equal to' value,
>> while an exclusive bound is a 'less than' or 'greater than' value.
>> Section 7.1 of the CF Conventions doesn't say it directly, but it
>> does state that contiguous cell boundaries are described by the
>> upper bound of one cell being equal to the lower bound of the next
>> cell. This implies that the upper bound is exclusive.
>>
>> Grace and peace,
>>
>> Jim
>>
>> On 3/12/15 12:46 PM, David Hassell wrote:
>>> Hi Paul, Jim,
>>>
>>> I'm not sure I follow the use of "inclusive" and "exclusive" (in
>>> particular I'm not sure what you mean by "CF upper bounds are always
>>> exclusive" - is this in the conventions?), but I agree that the upper
>>> bounds are at:
>>>
>>>    1960-01-01 00:00:00
>>>    1961-01-01 00:00:00
>>>    etc.
>>>
>>> to match up with the bounds values of
>>>
>>>    bounds_time =    // "days since 1955-1-1 0:0:0.0"
>>>      0, 1826,
>>>      365, 2192,
>>>      etc.
>>>
>>>
>>> All the best,
>>>
>>> David
>>>
>>> ---- Original message from Jim Biard (10AM 12 Mar 15)
>>>
>>>> Date: Thu, 12 Mar 2015 10:25:55 -0400
>>>> From: Jim Biard <jbiard at cicsnc.org>
>>>> To: cf-metadata at cgd.ucar.edu
>>>> Subject: Re: [CF-metadata] Overlapping time_bounds (running mean data)
>>>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
>>>>   Gecko/20100101 Thunderbird/31.5.0
>>>>
>>>> Paul,
>>>>
>>>> What you are doing is essentially perfect. Ferret is complaining,
>>>> but Ferret complains about a lot of things that are correct. It
>>>> assumes too much.
>>>>
>>>> There is one imperfection in your example: describing your upper
>>>> bounds as inclusive. CF upper bounds are always exclusive, so your
>>>> upper bounds should be 1960-01-01 00:00:00.0 and 1961-01-01
>>>> 00:00:00.0. Your days since 1955-01-01 00:00:00.0 upper bound values
>>>> in your example are correctly exclusive, so this isn't a "real"
>>>> problem here, but I've found that thinking about the upper bounds
>>>> the wrong way can lead to strangeness down the road, so I thought
>>>> I'd point it out.
>>>>
>>>> Your example also raises a question in my mind, so I'll throw an
>>>> off-track thought at you just for fun. Is there a driving reason why
>>>> you are choosing midnight on July 2 for some intervals and noon on
>>>> July 2 for others? I know that is the exact midpoint in each case,
>>>> but my tendency would be to pick either midnight or noon and use
>>>> that consistently. More specifically, I would pick YYYY-07-02
>>>> 12:00:00.0 for all my time variable values. That's just me, but
>>>> doing this is both valid (in particular since you have bounds that
>>>> makes the input range clear) and places the value unambiguously on
>>>> the same day in each year. This is more of a style issue, so don't
>>>> feel compelled to change anything unless you feel like it.
>>>>
>>>> Grace and peace,
>>>>
>>>> Jim
>>>>
>>>> On 3/11/15 8:24 PM, Durack, Paul J. wrote:
>>>>> Hi folks,
>>>>>
>>>>> I¹m generating a file which contains annual pentadal averaged data - so
>>>>> effectively a 5-year running mean saved with an annual time step. The file
>>>>> looks like:
>>>>>
>>>>> ---
>>>>> dimensions:
>>>>>          time = UNLIMITED ; // (56 currently)
>>>>>          bound = 2 ;
>>>>>          level = 26 ;
>>>>>          latitude = 180 ;
>>>>>          longitude = 360 ;
>>>>> variables:
>>>>>          float time(time) ;
>>>>>                  time:bounds = "bounds_time" ;
>>>>>                  time:units = "days since 1955-1-1 0:0:0.0" ;
>>>>>                  time:long_name = "time" ;
>>>>>                  time:standard_name = "time" ;
>>>>>                  time:calendar = "gregorian" ;
>>>>>                  time:axis = "T" ;
>>>>>          float bounds_time(time, bound) ;
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>> data:
>>>>> time = 913, 1278.5, 1644, 2009, 2374, 2739.5, 3105, 3470, 3835, 4200.5,
>>>>>      4566, 4931, 5296, 5661.5, 6027, 6392, 6757, 7122.5, 7488, 7853, 8218,
>>>>>      8583.5, 8949, 9314, 9679, 10044.5, 10410, 10775, 11140, 11505.5, 11871,
>>>>>      12236, 12601, 12966.5, 13332, 13697, 14062, 14427.5, 14793, 15158,
>>>>> 15523,
>>>>>      15888.5, 16254, 16619, 16984, 17349.5, 17715, 18080, 18445, 18810.5,
>>>>>      19176, 19541, 19906, 20271.5, 20637, 21002 ;
>>>>> bounds_time =
>>>>>    0, 1826,
>>>>>    365, 2192,
>>>>>    731, 2557,
>>>>>    1096, 2922,
>>>>> ...
>>>>>
>>>>>
>>>>> ---
>>>>>
>>>>> I¹m wondering what the most CF-like way of creating these bounds?
>>>>> Currently the bounds are specified as:
>>>>>
>>>>> Index 1:2
>>>>> 1955-1-1 0:0:0.0 -> 1959-12-31 12:59:59.0
>>>>> 1956-1-1 0:0:0.0 -> 1960-12-31 12:59:59.0
>>>>>
>>>>> And time values as above:
>>>>> Index 1:2
>>>>> 1957-7-2 0:0:0.0
>>>>> 1958-7-2 12:0:0.0
>>>>>
>>>>> When I try and load the file using Ferret, this throws a warning.. Which
>>>>> makes me think I¹m not doing things correctly:
>>>>>
>>>>> Ferret v6.93
>>>>> yes? use file.nc
>>>>>   *** NOTE: Axis definition error on axis: time. Bounds describe cells that
>>>>> overlap one another
>>>>>   *** NOTE: Error in bounds "bounds_time" or bounds do not enclose point on
>>>>> axis time
>>>>>   *** NOTE: Substituting coordinate midpoints
>>>>>
>>>>> Are there any tips for me regarding this, I wasn¹t able to find anything
>>>>> clear (at least to me) in the v1.7.2 Draft CF document.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> P
>>>>>
>>>>> _______________________________________________
>>>>> CF-metadata mailing list
>>>>> CF-metadata at cgd.ucar.edu
>>>> --
>>>> CICS-NC <http://www.cicsnc.org/> Visit us on
>>>> *Research Scholar*
>>>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
>>>> North Carolina State University <http://ncsu.edu/>
>>>> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
>>>> 151 Patton Ave, Asheville, NC 28801
>>>> e: jbiard at cicsnc.org
>>>> o: +1 828 271 4900
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CF-metadata mailing list
>>>> CF-metadata at cgd.ucar.edu
>>>
>>> --
>>> David Hassell
>>> National Centre for Atmospheric Science (NCAS)
>>> Department of Meteorology, University of Reading,
>>> Earley Gate, PO Box 243,
>>> Reading RG6 6BB, U.K.
>>>
>>> Tel   : +44 118 3785613
>>> E-mail: d.c.hassell at reading.ac.uk
>> --
>> CICS-NC <http://www.cicsnc.org/> Visit us on
>> *Research Scholar*
>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
>> North Carolina State University <http://ncsu.edu/>
>> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
>> 151 Patton Ave, Asheville, NC 28801
>> e: jbiard at cicsnc.org
>> o: +1 828 271 4900
>>
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>
>
> --
> David Hassell
> National Centre for Atmospheric Science (NCAS)
> Department of Meteorology, University of Reading,
> Earley Gate, PO Box 243,
> Reading RG6 6BB, U.K.
>
> Tel   : +44 118 3785613
> E-mail: d.c.hassell at reading.ac.uk

--
CICS-NC <http://www.cicsnc.org/> Visit us on
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900

-------------- next part --------------
An HTML attachment was scrubbed...