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
> >>>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>--
> >>CICS-NC <http://www.cicsnc.org/> Visit us on
> >>Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> >>*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
> >>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >
> >--
> >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
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *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
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
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
Received on Fri Mar 13 2015 - 04:44:24 GMT
