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/6fcb0d45/attachment-0001.html>
Received on Thu Aug 11 2011 - 15:26:42 BST
