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
>>>>>> 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
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> 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
>
> jim.biard at noaa.gov
> 828-271-4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110811/5ff0b4a2/attachment.html>
Received on Thu Aug 11 2011 - 15:34:02 BST
