Re: uniform handling of netcdf and grib files

Hi Jesper,

First of all, if you haven't yet done so, I would encourage you to
look over the GRIB section in the
"Data Formats Supported by the PyNIO module" web page:
http://www.pyngl.ucar.edu/NioFormats.shtml#GRIB
It has very detailed descriptions of how names for dimensions,
coordinate and data variables are formed and will
hopefully be useful in helping you handle them in a generic fashion.
Although we do not claim complete compliance with the CF-convention,
we have certainly made an
effort to be compatible with it in the PyNIO interface to GRIB.

Depending on the contents of the GRIB file there can be 0, 1, or 2
time dimensions. The possible dimensions
are initial time, representing the start time of a forecast series,
and the forecast time, usually the number of hours
from the initial time for which the forecast is intended. If the GRIB
file contains only one step along either of these
dimensions, PyNIO's default behavior is to give the value as an
attribute. That is apparently the case for the
initial time dimension in your test GRIB files. However, there is an
option that can be set for GRIB files called
'SingleElementDimensions' that allows you to force PyNIO to provide a
dimension and coordinate variable for
the initial time in this situation. When initial time is represented
using a coordinate variable the units will be
represented in a CF-compliant manner as 'hours since 1800-01-01
00:00'. CF does not, I far as I know, address
the distinction between initial time and forecast time, but in the
context of GRIB, the need for both is apparent.

Vertical levels that use hybrid sigma pressure coordinates use the CF-
compliant "formula_terms" attribute to
allow computation of the pressure at each grid point.

One dimensional coordinate variables are, in general, given the same
name as the dimension they represent.
When 2-D coordinates are required for data on rotated or other
projected grids, the CF-compliant
attribute 'coordinates' points from the data variable to the
applicable coordinate variables.

PyNIO does not provide the "standard_name" attribute or CF-compliant
attributes for map projection parameters. However,
it should be relatively easy to map from the attributes PyNIO uses to
describe map projections to the CF-authorized attributes.

Hope this helps.
  -dave

On Feb 29, 2008, at 6:29 AM, Jesper Larsen wrote:

> Hi,
>
> I am making an application which I would like to be able to process
> NetCDF files conforming to the Climate and Forecast (CF) Convention
> and
> GRIB files in a uniform manner. The application can already process
> the
> NetCDF files. I would therefore like to ask if I can depend on
> standardized attributes (mainly lon, lat, time and vertical level)
> attributes and variables in the NioFile and NioVariable objects for
> GRIB
> files?
>
> The GRIB files that I already have tested seem to have an integer
> variable (forecast_time[number]) which is the offset in some specified
> units (which seem to be defined in the grib standard), a variable
> specific initial time (initial_time) attribute with format mm/dd/yyyy
> (HH:MM), and the horizontal coordinates seem to be named
> [gridnumber]_lon_[number] and [gridnumber]_lat_[number] with units
> that
> are identical to the CF standard names (degrees_north and
> degrees_east).
> Unfortunately none of my files contain vertical levels.
>
> My application needs to be able to parse the coordinate variables in a
> generic manner. Is that task doable with a reasonable effort?
>
> I have only looked at grib files on regular grids where lon(lon) and
> lat(lat) and I am well aware that the above does not hold for for
> example rotated grids - but support for regular grids will be a start.
>
> Regards,
> Jesper
>
> _______________________________________________
> pyngl-talk mailing list
> pyngl-talk_at_ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/pyngl-talk

_______________________________________________
pyngl-talk mailing list
pyngl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/pyngl-talk
Received on Fri Feb 29 2008 - 15:17:35 MST