[CF-metadata] grid cells with a varying number of cell bounds

Jim Biard jbiard at cicsnc.org
Fri Sep 8 08:53:13 MDT 2017


I agree with you. I don't see a problem with the existing convention being
tweaked to state that fewer vertices for a cell are indicated by missing
values in the last elements.


[image: CICS-NC] <http://www.cicsnc.org/>Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC  <http://cicsnc.org/>
North Carolina State University  <http://ncsu.edu/>
NOAA National Centers for Environmental Information  <http://ncdc.noaa.gov/>
*formerly NOAA’s National Climatic Data Center*
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900

*Connect with us on Facebook for climate
<http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
Twitter at @NOAANCEIclimate
<http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo

On Fri, Sep 8, 2017 at 10:12 AM, Karl Taylor <taylor13 at llnl.gov> wrote:

> Dear Jonathan and all,
> 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.)
> 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).
> 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. *Mon. Wea. Rev.,**123,* 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.
> If we decide to eliminate the "old" option for handling these grid cells,
> we should:
> 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.
> 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.
> 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.
> best regards,
> Karl
> 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."
> 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?
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170908/27043994/attachment-0001.html>

More information about the CF-metadata mailing list