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
*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 _at_NOAANCEIclimate
<
http://www.twitter.com/NOAANCEIclimate>and _at_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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170908/27043994/attachment.html>
Received on Fri Sep 08 2017 - 08:53:13 BST
