I agree that bounds is necessary as it stands now. But it might look
cumbersome to many if they have to specify the bounds even for regular
grids. Probably the issue is already discussed and we have to live with
this or is there a better way? Couldn't bounds attribute, for example,
simply hold two values in case of regular grids and a string holding the
bounds variable in case of irregular grids?
Also, I see that attribute "cell_bounds" is used at several places in
the CF document but Table A.1 and some examples use the attribute
"bounds". I don't see cell_bounds in Table A.1.
Regards,
Upendra
On 8/11/2011 1:41 PM, Karl Taylor wrote:
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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata