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:
balaji at princeton.edu
https://www.gfdl.noaa.gov/v-balaji-homepage
On Fri, Sep 8, 2017 at 10:53 AM, Jim Biard <jbiard at cicsnc.org> 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: jbiard at cicsnc.org
> 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 _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
>>
>>
>
> _______________________________________________
> 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/2b6614e2/attachment.html>
Received on Fri Sep 08 2017 - 11:22:07 BST
