This was previously entered as a defect in Trac #64. It is now
awaiting further action.
https://cf-pcmdi.llnl.gov/trac/ticket/64
Apparently, "cell_bounds" was used in just three places, when the
intention was "the bounds attribute", along with the associated
boundary variable.
--Dave
On 8/11/2011 3:34 PM, Karl Taylor wrote:
Hi Jeff,
If no one else does it, could you, when you return next week, enter
this as a "defect", so we can correct it?
thanks,
Karl
On 8/11/11 2:26 PM, Jim Biard wrote:
As near as I can tell, the document shouldn't use the word
"cell_bounds". I think it is just an editorial glitch.
On 8/11/2011 5:07 PM, Upendra Dadi wrote:
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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
[email protected]
828-271-4900
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
