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.html>
Received on Fri Sep 08 2017 - 08:12:06 BST
