Hi all,
I'm not sure why we should assume anything if the bounds are missing.
Making an assumption would be valuable if the absence of bounds
invariably implied a rule (e.g., centers half-way between bounds), but
otherwise the assumption could be wrong, so what have we gained? I'm
not sure the CF conventions should be dictating a convention for
applications. I'd be in favor of dropping the sentence under discussion
entirely.
Note also that one cannot generally infer the location of the bounds
from the grid-points positions even with the assumption that they are at
the center of cells. For example, the following grid: 4 8
12 16 20 could be associated with various sets of bounds, for
example:
( 3,5) (5,11) (11,13) (13,19) (19,21) *or*
(2,6) (6,10) (10,14) (14,18) (18,22) *or* an
infinity of other possibilities.
It might especially be difficult to decide where to place the bounds in
the case of unevenly spaced grid-points.
So, saying the grid-point is at the mid-point of the cell doesn't tell
you much does it?
cheers,
Karl
On 8/11/11 9:33 AM, Steve Hankin wrote:
On 8/11/2011 9:14 AM, Upendra Dadi wrote:
Hi,
I have a related question about "bounds" attribute. I often see
regularly gridded latitude-longitude data which do not have "bounds"
specified when probably they should. But they almost always have
regularly spaced latitude and longitude values which are at the
middle of each cell. CF checkers have no way to identify the problem
since files are valid both ways even though CF implementations might
interpret them differently (do they?). My question is what are the
consequences of not having "bounds" for analysis operations that are
commonly used in various models.
Hi Upendra,
The introduction to CF Chapter 4 states:
"If bounds are not provided, an application might reasonably
assume the gridpoints to be at the centers of the cells, but we do
not require that in this standard. "
Arguably this could/should be tightened up to say "If bounds are not
provided, applications should assume the gridpoints to be at the
centers of the cells. " in order to remove any ambiguity. Opinions
whether there might be any backwards compatibility issues from this
change?
- Steve
Upendra
On 8/10/2011 8:31 AM, John Caron wrote:
On 8/8/2011 3:43 PM, Jim Biard wrote:
Hi.
I have a time series of monthly averaged values. I have an
integer-valued time coordinate variable and an associated
time_bounds variable. Is it correct to use the 15th of February
and the 16th of all the other months for my time centers, or should
I use the 16th of every month?
Also, should I do anything differently if my data are
climatological monthly averages (say, over 30 years of data)? And,
in this case, should the time coordinate values be day numbers from
the beginning of the 30-year time interval, the end of the time
interval, or something else entirely?
Grace and peace,
Jim Biard
At the moment, IMO the best that can be done in CF is to accurately
record the date range (using the bounds attribute). The coordinate
value should then be considered for labeling purposes only. Make a
one line description and put into the long_name attribute. Make sure
you have human readable documentation that explains whats going on
in detail, and add a global attribute that references it. Set up a
24-hour hotline to answer questions, staffed by post-docs wearing
beepers. Ok, maybe not the last ;^)
_______________________________________________
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
