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

V Balaji - NOAA Affiliate v.balaji at noaa.gov
Fri Sep 8 11:22:07 MDT 2017

The relevant section of the UGRID conventions
consistent with this (except _FillValue is suggested).

It goes on to say "...we may use in the future a ragged array, but here we
propose to use _FillValue to indicate faces with smaller number of nodes
than the arrays allow."

Scroll a bit down for a CDL example of a mesh with one triangle and one


V. Balaji                            Office:     +1-609-452-6516
Head, Modeling Systems Group, GFDL   Mobile:     +1-917-273-9824
Princeton University                 Email:
balaji at princeton.eduhttps://www.gfdl.noaa.gov/v-balaji-homepage

On Fri, Sep 8, 2017 at 10:53 AM, Jim Biard <jbiard at cicsnc.org> wrote:

> Karl,
> 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.
> Jim
> [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 <(828)%20271-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
> <http://www.twitter.com/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
> _______________________________________________
> 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/2b6614e2/attachment-0001.html>

More information about the CF-metadata mailing list