[CF-metadata] bounds for "reduced grids"

From: Brian Eaton <eaton>
Date: Thu, 29 Aug 2002 10:57:06 -0600 (MDT)

Hi Karl,

> afraid I don't. Maybe the grid_mapping method could be set
> to "reduced_grid" to define this type of grid explicitly.

The purpose of the "grid_mapping" attribute is to define the mapping that
allows one to calculate lat/lon from the actual grid coorinates. In the
case of the reduced grid there are no grid coordinates, just an index into
the uncompressed 2D array.

The way that a variable on a reduced grid is identified as such is by the
presence of a coordinate variable (rgrid in our example) with a "compress"
attribute.

> In this example we recommend that "this type of gridded data
> be stored using the compression scheme described in section
> 8.2" I guess we recommend this because if the software
> reading the data is smart enough, it can infer the grid
> structure, whereas without the compression attribute, this
> might not be possible. O.K., that seems like a good idea.

My initial draft of the reduced grid example used a full 2D array for the
longitudes, and that array contained missing values. I still think this is
much simpler than the compression scheme. The reason I consented to go
with the compression scheme is because there is sufficient information to
easily reconstruct the data on the reduced grid. I suspect that in
practice most applications will just skip the step of going to a reduced
grid and instead interpolate the data to some regular grid for plotting or
comparison with other data.

> Also, am I correct in the following interpretation?
> Software that makes use of the compress information must
> extract two pieces of information from the compress list.
> In the example, the software should look for the variables
> named "lat" and "lon" and discover that "lat" containes the
> latitude coordinate values and "lon" the longitude
> coordinate values. This tells it also that in uncompressing
> the data into a logically rectangular array, the order is
> ("latitude", "longitude").

Not exactly. The names in the compress list are dimensions, not variables.
The coordinates list (of PS) contains the names of the variables that are
checked to find the latitude and longitude auxiliary coordinates. I think it
would make the example clearer to change the dimension names to latdim and
londim. I'll do that.

> Things become even more complicated when we consider how to
> store the cell "bounds". The way to do this seems to be:

I agree with your example.

> 3) In the example, there is no guarantee that the lon
> coordinate values are ordered monotonically. In fact
> the reduced grid file we received had longitudes
> increasing from 0 to near 180, then switching to a
> value near -180 and increasing to near 0. This again
> may make it difficult to write smart and error-free
> software.

Yes. Since lon(rgrid) is not a coordinate variable, there are no
monotonicity constraints. But dealing with the periodic longitude
coordinate is a standard (not easy!) problem.

Hope that helps.
Brian
Received on Thu Aug 29 2002 - 10:57:06 BST