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

Karl Taylor taylor13 at llnl.gov
Wed Dec 20 15:21:53 MST 2017


Hi all,

It now becomes urgent to resolve this discussion.

My sense is that no one violently opposes the use of missing_value to 
fill unused vertices for grid cells with fewer than the maximum number 
of vertices.  For CMIP6 some models may need to define grids with a few 
cells having one less vertex than the majority.  I am (much too late in 
the process) writing down the data requirements for CMIP6 model output, 
and unless someone objects, I will specify that the missing_value can be 
used in this way.

My only qualm is that technically, some might regard such files as non 
compliant with CF, but in practice I don't think the non-compliance will 
have much (if any) impact.

Speak now, or forever hold your peace. (The wedding is imminent).

best regards,
Karl

On 9/12/17 8:08 AM, Whiteaker, Timothy L wrote:
>
> Wearing my simple geometry hat: While simple geometries could handle 
> this case, that proposal was intended to support discrete geospatial 
> features such as river segments or watershed areas, including 
> multi-part polygons such as Hawaii and polygons with holes such as a 
> lake polygon with an island in the middle.  It may be overkill for the 
> OP's use case.
>
> My humble opinion as a general netCDF user: Allowing missing values 
> seems simple and efficient for the OP's use case.  My only worry would 
> be that this solution introduces a competing method of encoding 
> discrete polygons like what the simple geometries proposal targets; 
> this would be alleviated with proper guidance on when to use these 
> various solutions in the CF documentation.  I also admit my ignorance 
> regarding prevalence of other grid cell configurations in datasets out 
> in the wild which the missing value solution wouldn't cleanly support, 
> or the impact of the missing value solution on netCDF software libraries.
>
> Regards,
>
> Tim Whiteaker
>
> Research Scientist
>
> The University of Texas at Austin
>
> *From:*CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] *On 
> Behalf Of *David Hassell
> *Sent:* Monday, September 11, 2017 4:22 AM
> *To:* Jonathan Gregory <j.m.gregory at reading.ac.uk>
> *Cc:* CF Metadata <cf-metadata at cgd.ucar.edu>
> *Subject:* Re: [CF-metadata] grid cells with a varying number of cell 
> bounds
>
> Hello,
>
> Coorecting an error in my last post:
>
> On 8 September 2017 at 17:51, David Hassell <david.hassell at ncas.ac.uk 
> <mailto:david.hassell at ncas.ac.uk>> wrote:
>
>     Hello Karl, Jonathan, Jim,
>
>     I also support Karl's suggested changes, with the possible
>     exception of insisting that the valid bounds values always precede
>     the any missing data. Whilst that is surely the easiest case for
>     software to deal with, and is an attractive restriction to me, it
>     that may not be how people want to do it, or have already done it
>     in the past.
>
>     ​​
>
>     I'm don't think that allowing this would not cause any more
>     confusion than is already (will be!) there with the inclusion of
>     simple geometries. As Jonathan points out, it would be "not
>     recommended" to use simple geometries when standard bounds
>     suffice. That advice easily includes standard bounds being allowed
>     missing values, I think.
>
> ​I had one too many negatives in last paragraph. It should have read:​
>
> ​​I'm *DO* think that allowing this would not cause any more confusion 
> than is already (will be!) there with the inclusion of simple 
> geometries. As Jonathan points out, it would be "not recommended" to 
> use simple geometries when standard bounds suffice. That advice easily 
> includes standard bounds being allowed missing values, I think.​
>
>>
> Sorry for the confusion,
>
> David​
>
>     All the best,
>
>     David
>
>     On 8 September 2017 at 16:24, Jonathan Gregory
>     <j.m.gregory at reading.ac.uk <mailto:j.m.gregory at reading.ac.uk>> wrote:
>
>         Dear Karl
>
>         I agree, other views are needed; it would be especially useful
>         to hear from
>         Dave Blodgett and other proposers of the simple geometries.
>         Although I agree
>         that what you describe is not necessarily inefficient (and in
>         the case you
>         mention it would be more efficient than the simple
>         geometries), and it's not
>         a large change to the existing convention, I do think it *is*
>         a change, since
>         we don't normally permit missing data in boundary variables.
>
>         I don't have a strong preference between the methods. What
>         discomforts me is
>         introducing two methods for doing the same thing. If we did
>         that, we should
>         give some clear guidance to data-writers about which to choose.
>
>         Of course, there is no suggestion that the simple geometries
>         approach should
>         replace the existing one for cells with polygons that all have
>         the same number
>         of vertices. Consistent with the last paragraph, I suggest
>         that we should
>         recommend the use of the existing convention for that case,
>         rather than the
>         simple geometries convention.
>
>         Best wishes
>
>         Jonathan
>
>         ----- Forwarded message from Karl Taylor <taylor13 at llnl.gov
>         <mailto:taylor13 at llnl.gov>> -----
>
>         > Date: Fri, 8 Sep 2017 07:12:06 -0700
>         > From: Karl Taylor <taylor13 at llnl.gov <mailto:taylor13 at llnl.gov>>
>         > To: cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>         > Subject: Re: [CF-metadata] grid cells with a varying number
>         of cell bounds
>         > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11;
>         rv:52.0)
>         >       Gecko/20100101 Thunderbird/52.2.1
>         >
>         > 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 <mailto:CF-metadata at cgd.ucar.edu>
>         > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>         ----- End forwarded message -----
>         _______________________________________________
>         CF-metadata mailing list
>         CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>         http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
>
>     -- 
>
>     David Hassell
>     National Centre for Atmospheric Science
>     Department of Meteorology, University of Reading,
>     Earley Gate, PO Box 243, Reading RG6 6BB
>     Tel: +44 118 378 5613 <tel:+44%20118%20378%205613>
>     http://www.met.reading.ac.uk/
>
>
>
>
> -- 
>
> David Hassell
> National Centre for Atmospheric Science
> Department of Meteorology, University of Reading,
> Earley Gate, PO Box 243, Reading RG6 6BB
> Tel: +44 118 378 5613
> http://www.met.reading.ac.uk/
>
>
>
> _______________________________________________
> 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/20171220/45fce233/attachment-0001.html>


More information about the CF-metadata mailing list