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 at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110811/5e20e574/attachment.html>
Received on Thu Aug 11 2011 - 11:41:16 BST
