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
>>>>>>> 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
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Aug 11 2011 - 21:12:10 BST
