⇐ ⇒

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

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 6 Sep 2017 18:39:27 +0100

Dear 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?

> Concerning missing values being permitted for "unused elements in
> discrete sampling geometries", I agree when a variable is not
> formally a function of time (as in examples H.3, H.16, and H.18,
> H.20, and H.21), then time may have missing_values, but not when the
> variable is formally a function of time as in H.4 and H.5, where
> time is actually a coordinate variable. I think in fact that the
> NUG forbids missing values in coordinate variables.

OK, sorry, I had overlooked that in this case there is a single timeseries,
so it's not one of the storage methods which could containing missing data
in coordinates. I agree, this is not allowed in (Unidata) coordinate vars,
and the document should be corrected in H.4 and H.5.

Best wishes

Jonathan
Received on Wed Sep 06 2017 - 11:39:27 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒