⇐ ⇒

[CF-metadata] cell metrics

From: Simon Wood <simon.wood>
Date: Thu, 05 Oct 2006 14:40:14 +1300

Hi Jonathan, Brian, and others

>>> * grid_cell_area and _height. These are metrics for the grid, rather than
>>> quantities which need standard names. Grid cell area should be specified
>>> by a
>>> cell_measures variable of area (CF 7.2). Grid cell height can be deduced
>>> as the
>>> difference between the lower and upper boundary in the vertical
>>> coordinate. If
>>> it has to be stored separately we could add a cell_measures for it.
>>>
>> Yes, I know that the cell_measures exist, but it is convenient to have
>> the grid information stored in variables. It would be nice if these
>> names could be added.
>
> Perhaps we could add standard names of area (m2) and thickness (m)? These are
> the generic names we already use in construction of others. To use them as
> standard names for extensive quantities that describe cell measurements seems
> logical to me. I wonder what others think.

Are you suggesting this as an alternative to the use of cell_measures or
are you just proposing standard names for the measure variables?

If the latter, then don't you also need
a) a standard name for 'cell_volume'? (since volume is already a
standard cell_measure name), and
b) a new cell_measure name of 'thickness' (or height), which would refer
to a measure variable with standard_name = 'cell_thickness'?

(I tend to agree with Brian that 'area' alone seems too ambiguous.)

If you do mean the former, then I'm curious as to the reason for
introducing an alternative method for specifying cell metrics in
addition to the existing cell bounds and cell_measures? Doesn't this
just complicate things, leading to possible confusion / ambiguity? Does
this make the use of cell_measures optional? (...obsolete?)

Put another way, are you proposing that (using the example from CF 7.2)
the following:

dimensions:
   cell = 2562 ; // number of grid cells
   time = 12 ;
   nv = 6 ; // maximum number of cell vertices
variables:
   float PS(time,cell) ;
     PS:units = "Pa" ;
     PS:coordinates = "lon lat" ;
     PS:cell_measures = "area: cell_area" ;
   float cell_area(cell) ;
     cell_area:long_name = "area of grid cell" ;
     cell_area:standard_name="area";
     cell_area:units = "m2"
   ...

can simply be represented as:

dimensions:
   cell = 2562 ; // number of grid cells
   time = 12 ;
   nv = 6 ; // maximum number of cell vertices
variables:
   float PS(time,cell) ;
     PS:units = "Pa" ;
     PS:coordinates = "lon lat" ;
     // ### note no cell_measures attribute
   float cell_area(cell) ;
     cell_area:long_name = "area of grid cell" ;
     cell_area:standard_name="cell_area";
     // ### use of standard name identifies 'cell_area' as a cell measure
     cell_area:units = "m2"
   ...

?

Maybe I've missed something, but I don't really see that this adds much
and surely it would lead to problems with existing CF aware applications
which should understand the former example, but whose treatment of the
latter would be undefined.


regards

Simon Wood

-- 
Simon Wood                                  Meteorology & Remote Sensing
Scientific Programmer                                               NIWA	
simon.wood at niwa.co.nz                              http://www.niwa.co.nz
Received on Wed Oct 04 2006 - 19:40:14 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒