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.html>
Received on Wed Dec 20 2017 - 15:21:53 GMT
