The relevant section of the UGRID conventions <https://ugrid-conventions.github.io/ugrid-conventions/#2d-flexible-mesh-mixed-triangles-quadrilaterals-etc-topology> seems 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 quadrilateral. Thanks, V. Balaji Office: +1-609-452-6516 Head, Modeling Systems Group, GFDL Mobile: +1-917-273-9824 Princeton University Email: [email protected]https://www.gfdl.noaa.gov/v-balaji-homepage On Fri, Sep 8, 2017 at 10:53 AM, Jim Biard <[email protected]> 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: [email protected] > 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 <[email protected]> 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 >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
