wradlib Documentation - Bitbucket

wradlib Documentation, Release 0.1.1
to descriptor values. E.g. if the descriptor identifier was (0, 30, 21), the descriptor name would be ‘Number of pixels
per row’ and the descriptor value could be an integer which actually specifies the number of rows of a grid. Just try:
# Gives the descriptor name for each descriptor ID tuple
print metadata[0]
# Gives the descriptor value for each descriptor name
print metadata[1]
# Gives the descriptor value for a particular descriptor ID tuple, in this case (0, 30, 21)
print metadata[1][ metadata[0][(0, 30, 21)] ]
Gotchas: At the moment, the BUFR implementation in wradlib has the potential to give you some trouble. It has
only been tested on Windows 7 under Python 2.6, yet. The key is that the BUFR software has to be successfully
compiled in the course of wradlib installation (via python setup.py install). Compilation requires gcc and make. Both
is pre-installed on most Linux machines, and can be installed on Windows using the MinGW compiler suite. If you
are using Python(x,y), gcc and make should already be available on your machine! You can check this by opening
a console window and typing gcc --version and mingw32-make --version. For Linux, the makefile is
available and we hope that the installation process works. But we never tested it! Please give us your feedback how it
works under Linux by sending an e-mail to wradlib-users@googlegroups.com or by raising an issue.
2.2.4 OPERA HDF5 (ODIM_H5)
HDF5 is a data model, library, and file format for storing and managing data. The OPERA 3 program developed a
convention (or information model) on how to store and exchange radar data in hdf5 format. It is based on the work
of COST Action 717 and is used e.g. in real-time operations in the Nordic European countries. The OPERA Data
and Information Model (ODIM) is documented e.g. in this report and in a UML representation. Make use of these
documents in order to understand the organization of OPERA hdf5 files!
The hierarchical nature of HDF5 can be described as being similar to directories, files, and links on a hard-drive.
Actual metadata are stored as so-called attributes, and these attributes are organized together in so-called groups.
Binary data are stored as so-called datasets. As for ODIM_H5, the root (or top level) group contains three groups of
metadata: these are called what (object, information model version, and date/time information), where (geographical
information), and how (quality and optional/recommended metadata). For a very simple product, e.g. a CAPPI, the
data is organized in a group called dataset1 which contains another group called data1 where the actual binary
data are found in data. In analogy with a file system on a hard-disk, the HDF5 file containing this simple product is
organized like this:
/
/what
/where
/how
/dataset1
/dataset1/data1
/dataset1/data1/data
The philosophy behind the wradlib interface to OPERA’s data model is very straightforward: wradlib simply translates
the complete file structure to one dictionary and returns this dictionary to the user. Thus, the potential complexity of
the stored data is kept and it is left to the user how to proceeed with this data. The keys of the output dictionary are
strings that correspond to the “directory trees” shown above. Each key ending with /data points to a Dataset (i.e. a
numpy array of data). Each key ending with /what, /where or /how points to another dictionary of metadata. The
entire output can be obtained by:
fcontent = io.read_OPERA_hdf5("mydrive:/path/to/my/file/filename")
The user should inspect the output obtained from his or her hdf5 file in order to see how access those items which
should be further processed. In order to get a readable overview of the output dictionary, one can use the pretty printing
module:
2.2. Supported radar data formats 15