Fwd: Re: [CF-metadata] cell metrics

[Steve Hankin]

Hi All,

Coming back from a few days of travel I see this lengthy thread of 
discussion about cell_measure.  I'd like to offer a couple of 
observations -- taking on my usual role as gadfly.  As background for 
the philosophy that guides me here I offer this quotation that Russ Rew 
presented at GO-ESSP in June:

    ... from "The Rise and Fall of CORBA" (Henning, 2006):

    *"To create quality software [or standards], the ability to say 'no'
    is usually far  more important than the ability to say 'yes.'"*

OK, with that curmudgeonly start  ;-) :

Some pretty basic issues have been raised here that seem to live on the 
boundary between "CF conventions" and "CF standard name".  

    * We are about to see the startup of a major new CF development in
      the area of so-called "unstructured grids".  This was an outcome
      of the GO-ESSP meeting in June.  These discussions should lead to
      a CF formulation  for non-rectangular grids that includes
      reference files, testing, and a requirement that multiple
      applications can read non-rectangular grid data from CF files. 
      Have these fundamental milestones been achieved at present with
      respect to any value of "nv" that is not a power of two?  For
      example the nv=6 "spherical geodesic grid" of example 7.3?  (It
      will be vital to know this as the unstructured grid work ramps
      up.)  If a concept has been written into the CF-1.0 document, but
      barely implemented in code and the same concept is going to be
      fully developed in another area of the standard might it make
      sense to leave the door open for deprecating a (minor) part of the
      version 1.0 standard?  Will it make sense to continue to allow nv
      to take on values that are not powers of two?

All I am really saying is that it is ok not to come to a decision so 
quickly.  This topic has been open for 24 hours and has generated 10 
messages.  (11 counting this curmudgeon's contribution.)  Maybe it needs 
a wider airing and some time to think about it in light of anticipated work.

But maybe not, too.  I have not tried to follow every word of the 
dialog.  Just urging caution.

    - Steve

=======================================================

Jonathan Gregory wrote:
> Dear Christiane
>
>   
>> Can I conclude from your discussion that standard names describing the 
>> grid are to be accepted as "data variables in their own right"? This was 
>> demanded by the HTAP community?
>>     
>
> I wonder whether anyone strongly disagrees. In the new CF process, as the old,
> consensus should be found if possible. I think Alison will sum up, as she
> posted yesterday.
>
>   
>> grid_cell_area
>> grid_cell_height
>>     
>
> (1) I would omit "grid" because of consistency with cell_measures and
> cell_methods, and because "grid" might imply that it is only relevant for,
> say, a 2D array of cells, which might not be the case; you could use such
> a variable even if there were only a single cell.
>
> (2) 
>   
>> For the latter I prefer height to thickness, because it indicates a 
>> vertical direction.
>>     
> In existing CF stdnames, "height" means distance above the surface, and
> "thickness" means vertical extent, so I think this measurement is a thickness.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>   

-- 
--

Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061005/eebcb8bb/attachment-0006.html>