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

Karl Taylor taylor13 at llnl.gov
Fri Sep 8 08:12:06 MDT 2017


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170908/24e755a1/attachment-0001.html>


More information about the CF-metadata mailing list