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 *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
