<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi all,<br>
    <br>
    It now becomes urgent to resolve this discussion.<br>
    <br>
    My sense is that no one violently opposes the use of missing_value
    to fill unused vertices for grid cells with fewer than the maximum
    number of vertices.  For CMIP6 some models may need to define grids
    with a few cells having one less vertex than the majority.  I am
    (much too late in the process) writing down the data requirements
    for CMIP6 model output, and unless someone objects, I will specify
    that the missing_value can be used in this way.  <br>
    <br>
    My only qualm is that technically, some might regard such files as
    non compliant with CF, but in practice I don't think the
    non-compliance will have much (if any) impact.<br>
    <br>
    Speak now, or forever hold your peace. (The wedding is imminent). <br>
    <br>
    best regards,<br>
    Karl<br>
    <br>
    <div class="moz-cite-prefix">On 9/12/17 8:08 AM, Whiteaker, Timothy
      L wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:MWHPR06MB3214BAF9DBCBF9E6117CAEEFD4690@MWHPR06MB3214.namprd06.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.gmail-hoenzb
        {mso-style-name:gmail-hoenzb;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Wearing
            my simple geometry hat: While simple geometries could handle
            this case, that proposal was intended to support discrete
            geospatial features such as river segments or watershed
            areas, including multi-part polygons such as Hawaii and
            polygons with holes such as a lake polygon with an island in
            the middle.  It may be overkill for the OP's use case. 
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">My
            humble opinion as a general netCDF user: Allowing missing
            values seems simple and efficient for the OP's use case.  My
            only worry would be that this solution introduces a
            competing method of encoding discrete polygons like what the
            simple geometries proposal targets; this would be alleviated
            with proper guidance on when to use these various solutions
            in the CF documentation.  I also admit my ignorance
            regarding prevalence of other grid cell configurations in
            datasets out in the wild which the missing value solution
            wouldn't cleanly support, or the impact of the missing value
            solution on netCDF software libraries.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Regards,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Tim
            Whiteaker<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Research
            Scientist<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The
            University of Texas at Austin<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><b><span
              style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
            CF-metadata [<a class="moz-txt-link-freetext" href="mailto:cf-metadata-bounces@cgd.ucar.edu">mailto:cf-metadata-bounces@cgd.ucar.edu</a>]
            <b>On Behalf Of </b>David Hassell<br>
            <b>Sent:</b> Monday, September 11, 2017 4:22 AM<br>
            <b>To:</b> Jonathan Gregory
            <a class="moz-txt-link-rfc2396E" href="mailto:j.m.gregory@reading.ac.uk"><j.m.gregory@reading.ac.uk></a><br>
            <b>Cc:</b> CF Metadata <a class="moz-txt-link-rfc2396E" href="mailto:cf-metadata@cgd.ucar.edu"><cf-metadata@cgd.ucar.edu></a><br>
            <b>Subject:</b> Re: [CF-metadata] grid cells with a varying
            number of cell bounds<o:p></o:p></span></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <div>
            <p class="MsoNormal"><span style="font-family:"Courier
                New"">Hello,<o:p></o:p></span></p>
          </div>
          <div>
            <p class="MsoNormal"><span style="font-family:"Courier
                New""><o:p> </o:p></span></p>
          </div>
          <div>
            <p class="MsoNormal"><span style="font-family:"Courier
                New"">Coorecting an error in my last post:<o:p></o:p></span></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
            <div>
              <p class="MsoNormal">On 8 September 2017 at 17:51, David
                Hassell <<a href="mailto:david.hassell@ncas.ac.uk"
                  target="_blank" moz-do-not-send="true">david.hassell@ncas.ac.uk</a>>
                wrote:<o:p></o:p></p>
              <blockquote style="border:none;border-left:solid #CCCCCC
                1.0pt;padding:0in 0in 0in
                6.0pt;margin-left:4.8pt;margin-right:0in">
                <div>
                  <div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New"">Hello
                        Karl, Jonathan, Jim,<o:p></o:p></span></p>
                  </div>
                  <div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New""><o:p> </o:p></span></p>
                  </div>
                  <div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New"">I
                        also support Karl's suggested changes, with the
                        possible exception of insisting that the valid
                        bounds values always precede the any missing
                        data. Whilst that is surely the easiest case for
                        software to deal with, and is an attractive
                        restriction to me, it that may not be how people
                        want to do it, or have already done it in the
                        past.<o:p></o:p></span></p>
                  </div>
                  <div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New""><o:p> </o:p></span></p>
                  </div>
                  <div>
                    <div>
                      <p class="MsoNormal"><span
                          style="font-family:"Cambria
                          Math",serif">​​</span><span
                          style="font-family:"Courier New""><o:p></o:p></span></p>
                    </div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New"">I'm
                        don't think that allowing this would not cause
                        any more confusion than is already (will be!)
                        there with the inclusion of simple geometries.
                        As Jonathan points out, it would be "not
                        recommended" to use simple geometries when
                        standard bounds suffice. That advice easily
                        includes standard bounds being allowed missing
                        values, I think.<o:p></o:p></span></p>
                  </div>
                </div>
              </blockquote>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <div>
                  <p class="MsoNormal"><span
                      style="font-family:"Cambria Math",serif">​</span><span
                      style="font-family:"Courier New"">I had
                      one too many negatives in last paragraph. It
                      should have read:</span><span
                      style="font-family:"Cambria Math",serif">​</span><span
                      style="font-family:"Courier New""><o:p></o:p></span></p>
                </div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <div>
                  <p class="MsoNormal"><span
                      style="font-family:"Cambria Math",serif">​​</span><span
                      style="font-family:"Courier New"">I'm
                      *DO* think that allowing this would not cause any
                      more confusion than is already (will be!) there
                      with the inclusion of simple geometries. As
                      Jonathan points out, it would be "not recommended"
                      to use simple geometries when standard bounds
                      suffice. That advice easily includes standard
                      bounds being allowed missing values, I think.</span><span
                      style="font-family:"Cambria Math",serif">​</span><span
                      style="font-family:"Courier New""><o:p></o:p></span></p>
                </div>
              </div>
              <div>
                <div>
                  <p class="MsoNormal"><span
                      style="font-family:"Cambria Math",serif">​</span><span
                      style="font-family:"Courier New""><o:p></o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
                      style="font-family:"Courier New"">Sorry
                      for the confusion,<o:p></o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
                      style="font-family:"Courier New""><o:p> </o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
                      style="font-family:"Courier New"">David</span><span
                      style="font-family:"Cambria Math",serif">​</span><span
                      style="font-family:"Courier New""><o:p></o:p></span></p>
                </div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal"> <o:p></o:p></p>
              </div>
              <blockquote style="border:none;border-left:solid #CCCCCC
                1.0pt;padding:0in 0in 0in
                6.0pt;margin-left:4.8pt;margin-right:0in">
                <div>
                  <div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New"">All
                        the best,<o:p></o:p></span></p>
                  </div>
                  <div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New""><o:p> </o:p></span></p>
                  </div>
                  <div>
                    <p class="MsoNormal"><span
                        style="font-family:"Courier New"">David<o:p></o:p></span></p>
                  </div>
                </div>
                <div>
                  <p class="MsoNormal"><o:p> </o:p></p>
                  <div>
                    <p class="MsoNormal">On 8 September 2017 at 16:24,
                      Jonathan Gregory <<a
                        href="mailto:j.m.gregory@reading.ac.uk"
                        target="_blank" moz-do-not-send="true">j.m.gregory@reading.ac.uk</a>>
                      wrote:<o:p></o:p></p>
                    <blockquote style="border:none;border-left:solid
                      #CCCCCC 1.0pt;padding:0in 0in 0in
                      6.0pt;margin-left:4.8pt;margin-right:0in">
                      <p class="MsoNormal">Dear Karl<br>
                        <br>
                        I agree, other views are needed; it would be
                        especially useful to hear from<br>
                        Dave Blodgett and other proposers of the simple
                        geometries. Although I agree<br>
                        that what you describe is not necessarily
                        inefficient (and in the case you<br>
                        mention it would be more efficient than the
                        simple geometries), and it's not<br>
                        a large change to the existing convention, I do
                        think it *is* a change, since<br>
                        we don't normally permit missing data in
                        boundary variables.<br>
                        <br>
                        I don't have a strong preference between the
                        methods. What discomforts me is<br>
                        introducing two methods for doing the same
                        thing. If we did that, we should<br>
                        give some clear guidance to data-writers about
                        which to choose.<br>
                        <br>
                        Of course, there is no suggestion that the
                        simple geometries approach should<br>
                        replace the existing one for cells with polygons
                        that all have the same number<br>
                        of vertices. Consistent with the last paragraph,
                        I suggest that we should<br>
                        recommend the use of the existing convention for
                        that case, rather than the<br>
                        simple geometries convention.<br>
                        <br>
                        Best wishes<br>
                        <br>
                        Jonathan<br>
                        <br>
                        ----- Forwarded message from Karl Taylor <<a
                          href="mailto:taylor13@llnl.gov"
                          target="_blank" moz-do-not-send="true">taylor13@llnl.gov</a>>
                        -----<br>
                        <br>
                        > Date: Fri, 8 Sep 2017 07:12:06 -0700<br>
                        > From: Karl Taylor <<a
                          href="mailto:taylor13@llnl.gov"
                          target="_blank" moz-do-not-send="true">taylor13@llnl.gov</a>><br>
                        > To: <a
                          href="mailto:cf-metadata@cgd.ucar.edu"
                          target="_blank" moz-do-not-send="true">cf-metadata@cgd.ucar.edu</a><br>
                        > Subject: Re: [CF-metadata] grid cells with
                        a varying number of cell bounds<br>
                        > User-Agent: Mozilla/5.0 (Macintosh; Intel
                        Mac OS X 10.11; rv:52.0)<br>
                        >       Gecko/20100101 Thunderbird/52.2.1<br>
                        ><br>
                        > Dear Jonathan and all,<br>
                        ><br>
                        > Regarding the options for representing
                        polygon cells with varying<br>
                        > number of sides (see below), I agree that
                        the "simple geometries"<br>
                        > proposal can indeed handle this case. ( It
                        of course could also<br>
                        > 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<br>
                        > method of storing data on these grids using
                        the old method with cell<br>
                        > bounds described by their vertices (without
                        the need for<br>
                        > "containers").  Certainly, I would want to
                        retain the current<br>
                        > treatment  when dealing with cells having
                        the  *same* number of<br>
                        > sides.  I also favor an option to use our
                        current method (which is<br>
                        > however incompletely described, as I've
                        pointed out) to handle grids<br>
                        > with cells of different shapes.  All we
                        would need to make the<br>
                        > current method well-described is to specify
                        that the bounds could<br>
                        > include "missing_values" when the number of
                        grid cell vertices were<br>
                        > fewer than the maximum specified in the
                        dimension statement (and the<br>
                        > 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<br>
                        > Heikes, R., and D. A. Randall, 1995a:
                        Numerical integration of the<br>
                        > shallow-water equations on a twisted
                        icosahedral grid. Part I: Basic<br>
                        > design and results of tests. /Mon. Wea.
                        Rev.,/*123,* 1862–1880), all<br>
                        > the grid cells except 12 are hexagons.  The
                        12 exceptions come from<br>
                        > the "corners" of a cube and are pentagons.
                        This means that the cell<br>
                        > bounds would contain only 12
                        missing_values, so not a significant<br>
                        > problem with wasting storage.<br>
                        ><br>
                        > If we decide to eliminate the "old" option
                        for handling these grid<br>
                        > cells, we should:<br>
                        ><br>
                        > 1) first poll the modeling groups to see if
                        anyone knows of any<br>
                        > attempts to use the current CF conventions
                        to store data on such<br>
                        > grids.  If not, then changing the standard
                        won't have any real<br>
                        > consequences on legacy datasets.<br>
                        ><br>
                        > 2)  Provide an example in the proposed
                        section 7.5 illustrating how<br>
                        > an icosahedral grid like the one referenced
                        above would be stored. I<br>
                        > must say I think few would be able to
                        quickly read section 7.5 and<br>
                        > be able to successfully store CF-compliant
                        data on such grids;  the<br>
                        > 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<br>
                        > most users wouldn't find it easier in the
                        case under consideration<br>
                        > here, to interpret datasets stored with the
                        older method?  Hope to<br>
                        > hear other views on this.<br>
                        ><br>
                        > best regards,<br>
                        > Karl<br>
                        ><br>
                        ><br>
                        > >>I certainly always envisaged the
                        possibility of cells of different<br>
                        > >>shapes, and we imply that this
                        might be the case in the description<br>
                        > >>of cell bounds with the explicit
                        mention of "maximum":<br>
                        > >><br>
                        > >>/"A boundary variable will have one
                        more dimension than its<br>
                        > >>associated coordinate or auxiliary
                        coordinate variable./ The<br>
                        > >>additional dimension should be the
                        most rapidly varying one, and its<br>
                        > >>size is the maximum number of cell
                        vertices."<br>
                        > >That's true. Nonetheless we didn't
                        provide for it later on in the document!<br>
                        > ><br>
                        > >Well, now we have a choice. Dave
                        Blodgett's proposal has been debated and<br>
                        > >revised over many months, and I support
                        it in its current form. That is a<br>
                        > >more general solution, which allows not
                        only mixtures of different sorts of<br>
                        > >polygons, but also sets of
                        discontiguous polygons (for each cell), polygons<br>
                        > >with holes in them, and lines. It does
                        not require missing data to be stored<br>
                        > >in the bounds, because it has a count
                        of how many vertices belong to each cell.<br>
                        > >Permitting missing data in polygon
                        bounds in sect 7.1 would be a different<br>
                        > >way of describing a mixture of
                        different sorts of polygons. Providing more<br>
                        > >than one method to do this would
                        introduce unnecessary complexity. How do you<br>
                        > >and others think we should choose?<br>
                        > ><br>
                        > ><br>
                        ><br>
                        <br>
                        >
                        _______________________________________________<br>
                        > CF-metadata mailing list<br>
                        > <a href="mailto:CF-metadata@cgd.ucar.edu"
                          target="_blank" moz-do-not-send="true">CF-metadata@cgd.ucar.edu</a><br>
                        > <a
                          href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata"
                          target="_blank" moz-do-not-send="true">
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a><br>
                        <br>
                        <br>
                        ----- End forwarded message -----<br>
                        _______________________________________________<br>
                        CF-metadata mailing list<br>
                        <a href="mailto:CF-metadata@cgd.ucar.edu"
                          target="_blank" moz-do-not-send="true">CF-metadata@cgd.ucar.edu</a><br>
                        <a
                          href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata"
                          target="_blank" moz-do-not-send="true">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a><o:p></o:p></p>
                    </blockquote>
                  </div>
                  <p class="MsoNormal"><span style="color:#888888"><br>
                      <br clear="all">
                      <br>
                      <span class="gmail-hoenzb">-- <o:p></o:p></span></span></p>
                  <div>
                    <div>
                      <div>
                        <div>
                          <div>
                            <div>
                              <div>
                                <div>
                                  <div>
                                    <div>
                                      <div>
                                        <p class="MsoNormal"><span
                                            style="font-family:"Courier
                                            New";color:#888888">David
                                            Hassell<br>
                                            National Centre for
                                            Atmospheric Science<br>
                                            Department of Meteorology,
                                            University of Reading,<br>
                                            Earley Gate, PO Box 243,
                                            Reading RG6 6BB<br>
                                            Tel: <a
                                              href="tel:+44%20118%20378%205613"
                                              target="_blank"
                                              moz-do-not-send="true">+44
                                              118 378 5613</a><br>
                                            <a
                                              href="http://www.met.reading.ac.uk/"
                                              target="_blank"
                                              moz-do-not-send="true">http://www.met.reading.ac.uk/</a></span><span
                                            style="color:#888888">
                                          </span><o:p></o:p></p>
                                      </div>
                                    </div>
                                  </div>
                                </div>
                              </div>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </blockquote>
            </div>
            <p class="MsoNormal"><br>
              <br clear="all">
              <br>
              -- <o:p></o:p></p>
            <div>
              <div>
                <div>
                  <div>
                    <div>
                      <div>
                        <div>
                          <div>
                            <div>
                              <div>
                                <div>
                                  <p class="MsoNormal"><span
                                      style="font-family:"Courier
                                      New"">David Hassell<br>
                                      National Centre for Atmospheric
                                      Science<br>
                                      Department of Meteorology,
                                      University of Reading,<br>
                                      Earley Gate, PO Box 243, Reading
                                      RG6 6BB<br>
                                      Tel: +44 118 378 5613<br>
                                      <a
                                        href="http://www.met.reading.ac.uk/"
                                        target="_blank"
                                        moz-do-not-send="true">http://www.met.reading.ac.uk/</a></span>
                                    <o:p></o:p></p>
                                </div>
                              </div>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
CF-metadata mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>