Dear all,
I agree with Jonathan that since it may not always be possible to
determine which cell_areas go with each field stored in a file (when
more than one grid is found in the file), the cell_measures attribute
should alway be defined.
CF enabled software should not be expected to determine the
cell_measures that go with each field by examining the standard names
and grids.
Furthermore, although I certainly don't object to having standard names
for the different cell_measures, those names (like all other standard
names) should not be required for compliance with CF.
Karl
Jonathan Gregory wrote:
> Dear Simon, Christiane, et al.
>
>>>>> * 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)?
>> Are you suggesting this as an alternative to the use of cell_measures or
>> are you just proposing standard names for the measure variables?
>
> It is not an alternative to cell measures. The proposal, from Christiane, was
> for a standard name for such quantities as data variables in their own right.
> Such data variables could also be pointed to by cell_measures.
>
>> 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?)
>
> I also asked whether it was necessary (in the >>>> text at the top). I think
> cell_measures would in any case remain useful as a pointer to locate the
> metrics easily. Sometimes cell_measures is not necessary because you could
> find the metric variable by searching the file for a data variable with the
> appropriate standard name (if we defined these) and the same grid as the data
> variable, but this is more laborious, and as your example shows it could be
> insufficient if the lat-lon coordinates are not defined. We probably had this
> discussion when we introduced cell_measures. It would be interested to know if
> anyone else has views.
>
>> a) a standard name for 'cell_volume'? (since volume is already a
>> standard cell_measure name), and
> Yes, we could do.
>
>> b) a new cell_measure name of 'thickness' (or height), which would refer
>> to a measure variable with standard_name = 'cell_thickness'?
> Yes, possibly.
>
> Neither of these has been requested and, as usual, we would not add them unless
> they were specifically asked for.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Thu Oct 05 2006 - 09:24:40 BST
