<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Dear Jonathan and all,<br>
    <br>
    Regarding the options for representing polygon cells with varying
    number of sides (see below), I agree that the "simple geometries"
    proposal can indeed handle this case. ( It of course could also
    handle the case when all grid cells have the same number of sides.)<br>
    <br>
    I think, however, it might be a mistake to rule out the alternative
    method of storing data on these grids using the old method with cell
    bounds described by their vertices (without the need for
    "containers").  Certainly, I would want to retain the current
    treatment  when dealing with cells having the  *same* number of
    sides.  I also favor an option to use our current method (which is
    however incompletely described, as I've pointed out) to handle 
    grids with cells of different shapes.  All we would need to make the
    current method well-described is to specify that the bounds could
    include "missing_values" when the number of grid cell vertices were
    fewer than the maximum specified in the dimension statement (and the
    missing_values would be the last ones in the bounds dimension).  <br>
    <br>
    I would point out that for at least one icosahedral grid (see
    Heikes, R., and D. A. Randall, 1995a: Numerical integration of the
    shallow-water equations on a twisted icosahedral grid. Part I: Basic
    design and results of tests. <i>Mon. Wea. Rev.,</i><b>123,</b>
    1862–1880), all the grid cells except 12 are hexagons.  The 12
    exceptions come from the "corners" of a cube and are pentagons. 
    This means that the cell bounds would contain only 12
    missing_values, so not a significant problem with wasting storage.<br>
    <br>
    If we decide to eliminate the "old" option for handling these grid
    cells, we should:<br>
    <br>
    1) first poll the modeling groups to see if anyone knows of any
    attempts to use the current CF conventions to store data on such
    grids.  If not, then changing the standard won't have any real
    consequences on legacy datasets.<br>
    <br>
    2)  Provide an example in the proposed section 7.5 illustrating how
    an icosahedral grid like the one referenced above would be stored. 
    I must say I think few would be able to quickly read section 7.5 and
    be able to successfully store CF-compliant data on such grids;  the
    current method, on the other hand, is easy to understand.<br>
    <br>
    I have no problem allowing the new method to be used, but wonder if
    most users wouldn't find it easier in the case under consideration
    here, to interpret datasets stored with the older method?  Hope to
    hear other views on this.<br>
    <br>
    best regards,<br>
    Karl<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:20170906173927.GA8669@met.reading.ac.uk">
      <blockquote type="cite">
        <pre wrap="">I certainly always envisaged the possibility of cells of different
shapes, and we imply that this might be the case in the description
of cell bounds with the explicit mention of "maximum":

/"A boundary variable will have one more dimension than its
associated coordinate or auxiliary coordinate variable./ The
additional dimension should be the most rapidly varying one, and its
size is the maximum number of cell vertices."
</pre>
      </blockquote>
      <pre wrap="">
That's true. Nonetheless we didn't provide for it later on in the document!

Well, now we have a choice. Dave Blodgett's proposal has been debated and
revised over many months, and I support it in its current form. That is a
more general solution, which allows not only mixtures of different sorts of
polygons, but also sets of discontiguous polygons (for each cell), polygons
with holes in them, and lines. It does not require missing data to be stored
in the bounds, because it has a count of how many vertices belong to each cell.
Permitting missing data in polygon bounds in sect 7.1 would be a different
way of describing a mixture of different sorts of polygons. Providing more
than one method to do this would introduce unnecessary complexity. How do you
and others think we should choose?

</pre>
      <br>
    </blockquote>
    <br>
  </body>
</html>