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:[email protected]] *On
Behalf Of *David Hassell
*Sent:* Monday, September 11, 2017 4:22 AM
*To:* Jonathan Gregory <[email protected]>
*Cc:* CF Metadata <[email protected]>
*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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> -----
> Date: Fri, 8 Sep 2017 07:12:06 -0700
> From: Karl Taylor <[email protected]
<mailto:[email protected]>>
> To: [email protected] <mailto:[email protected]>
> 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
> [email protected] <mailto:[email protected]>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
