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 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
>
>
> _______________________________________________
> 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/354afc5d/attachment.html>
Received on Thu Aug 11 2011 - 15:07:04 BST
