On 19-02-15 18:56, Jim Biard wrote:
Maarten,It would, instead be something like this: dimensions: lon = 360; lat = 180; layer = 18; vertices = 2; variables: float lat(lat); lat:long_name = "latitude"; lat:units = "degrees_north"; lat:bounds = "lat_bnds"; float lon(lon); lon:long_name = "longitude"; lon:units = "degrees_east"; lon:bounds = "lon_bnds"; float pressure(layer, lon, lat); pressure:long_name = "pressure grid"; pressure:units = "hPa"; pressure:bounds = "pressure_bnds"; float lat_bnds(lon,vertices); float lon_bnds(lat,vertices); float pressure_bnds(layer,lon,lat,vertices); float O3(layer, lon, lat); O3:units = "1e-9"; O3:coordinates = "pressure"; You can have a layer index coordinate variable if you require/desire one, but it isn't necessary. The bounds attribute is applied to the pressure variable, and a coordinates attribute is applied to the O3 variable naming the pressure variable. The pressure variable is an "auxiliary coordinate", and must be explicitly associated with the O3 variable in this way.
Thanks, but my colleague has a remark: "this is very inefficient" (although it is CF compliant).
Only the pressure boundaries are of interest, the pressures themselves are pretty much a dummy variable, although a pretty large dummy variable: 18*360*180 elements. Then the interfaces: 18*360*180*2. so instead of storing (18+1)*360*180, the storage requirement jumps to 3*18*360*180, or 2.84 times as much. Not a fantastic score. Especially for vertical coordinates this is a common situation
For regular coordinates the overhead is there, but at least it is a lot smaller. For irregular grids, this overhead is large, and adds variables no user will ever need. I'll think if I can think of a neat solution that can be used in CF2.
Best, Maarten Sneep -- KNMI T: 030 2206747 E: [email protected] R: A2.14 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
