[CF-metadata] bounds for "reduced grids"

From: Karl E.Taylor <taylor13>
Date: Wed, 28 Aug 2002 16:31:55 -0700

Dear all,

At PCMDI we are now receiving data on grids that are not the
regular latitude x longitude arrays. In particular we have
received a "reduced" longitude-latitude grid with the number
of longitudes depending on latitude. In trying to determine
whether the data is CF-compliant, I became confused reading
the example in section 5.3. I'm writing to see if anyone
has some idea how we might make it easier to follow; I'm
afraid I don't. Maybe the grid_mapping method could be set
to "reduced_grid" to define this type of grid explicitly.

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.

The reason I had trouble understanding the example, is that
two dimensions (lon and lat) were defined to be 128 and
64, but none of the variables in the file requires either
of these, unless you want some help inferring the grid
structure. Furthermore, the two "coordinates" are also
named lon and lat (but both are dimensioned rgrid). I
think this is the confusing aspect of the example.

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"). The software must also look for the
"dimensions" named "lat" and "lon" to determine what size to
define the "uncompressed" representation of the grid (64,128).
Furthermore, the software must use the "lon" dimension (128)
to construct the index values (j=rgrid(n)/128; i=regrid(n) - 128*j).

I don't see any way to simplify things, but I think we're
expecting both the data writers and the software writers
to work pretty hard here.

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

dimensions:
  lon = 128;
  lat = 64 ;
  rgrid = 6144 ;
variables:
  float PS(rgrid) ;
    PS:long_name = "surface pressure" ;
    PS:units = "Pa" ;
    PS:coordinates = "lon lat" ;
  float lon(rgrid) ;
    lon:long_name = "longitude" ;
    lon:units = "degrees_east" ;
    lon:bounds = "lon_bounds" ;
  float lat(regrid) ;
    lat:long_name = "latitude" ;
    lat:units = "degrees_north" ;
    lat:bounds = "lat_bounds" ;
  int rgrid(rgrid) ;
    rgrid:compress = "lat lon" ;
  float lon_bounds(rgrid,2) ;
  float lat_bounds(rgrid,2) ;


Some comments follow:

   1) Although lat_bounds in this case could be specified
      more concisely as lat_bounds(lat,2), I don't think
      we can allow this.

   2) Also, one way to graph the data, is to use a polygon
      fill algorithm, but this requires that the vertices
      be known. It's not trivial to construct the vertices
      given the bounds supplied in the above example (although
      it is also not terribly difficult).

   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.

Please let me know if I've incorrectly represented the bounds
in the above example. Any other comments are also welcome.

Karl
Received on Wed Aug 28 2002 - 17:31:55 BST