wradlib Documentation - Bitbucket

More documents

Recommendations

Info

$LaTeX-Tutorium III - Bitbucket$

wradlib Documentation, Release 0.1.1 data provides an extensive introduction into working with DX data. For now, we would just like to know how to read the data: data, metadata = io.readDX("mydrive:/path/to/my/file/filename") Here, data is a two dimensional array of shape (number of azimuth angles, number of range gates). This means that the number of rows of the array corresponds to the number of azimuth angles of the radar sweep while the number of columns corresponds to the number of range gates per ray. 2.2.2 German Weather Service: RADOLAN (quantitative) composit The quantitative composite format of the DWD (German Weather Service) was established in the course of the RADOLAN project. Most quantitative composite products from the DWD are distributed in this format, e.g. the R-series (RX, RY, RH, RW, ...), the S-series (SQ, SH, SF, ...), and the E-series (European quantitative composite, e.g. EZ, EH, EB). Please see the composite format description for a full reference and a full table of products (unfortunately only in German language). Currently, the RADOLAN composites have a spatial resolution of 1km x 1km, with the national composits (R- and S-series) being 900 x 900 grids, and the European composits 1500 x 1400 grids. The projection is polar-stereographic. The products can be read by the following function: data, metadata = io.read_RADOLAN_composite("mydrive:/path/to/my/file/filename") Here, data is a two dimensional integer array of shape (number of rows, number of columns). Different product types might need different levels of postprocessing, e.g. if the product contains rain rates or accumulations, you will normally have to divide data by factor 10. metadata is again a dictionary which provides metadata from the files header section, e.g. using the keys producttype, datetime, intervalseconds, nodataflag. Masking the NoData (or missing) values can be done by: import numpy as np maskeddata = np.ma.masked_equal(data, attrs["nodataflag"]) 2.2.3 OPERA BUFR The Binary Universal Form for the Representation of meteorological data (BUFR) is a binary data format maintained by the World Meteorological Organization (WMO). The BUFR format was adopted by the OPERA program for the representation of weather radar data. This module provides a wrapper around the OPERA BUFR software, currently only for decoding BUFR files. If you intend to work with BUFR data, we recommend reading OPERA’s BUFR software documentation. Please note that the way the BUFR software is wrapped has to be considered very preliminary. Due to yet unsolved problems with the BUFR software API, wradlib simply calls the executable for BUFR deoding (decbufr) and read and parses corresponding the file output. This is of course inefficient from a computational perpective. we hope to come up with a new solution in the near future. However, the wradlib BUFR interface is plain simple: data, metadata = io.read_BUFR("mydrive:/path/to/my/file/filename") Basically, a BUFR file consists of a set of descriptors which contain all the relevant metadata and a data section. The descriptors are identified as a tuple of three integers. The meaning of these tupels is described in the BUFR tables which come with the software. There are generic BUFR tables provided by the WMO, but it is also possible to define so called local tables - which was done by the OPERA consortium for the purpose of radar data representation. wradlib.io.read_BUFR returns a two element tuple. The first element (data) of the return tuple is the actual data array. It is a multi-dimensional numpy array of which the shape depends on the descriptor specifications (mostly it will be 2-dimensional). The second element (metadata) is a tuple of two dictionaries (descnames, descvals). descnames relates the descriptor identifiers to comprehensible descriptor names. descvals relates the descriptor names 14 Chapter 2. Tutorials
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
Page 1: wradlib Documentation Release 0.1.1
Page 4 and 5: 5.3 Users . . . . . . . . . . . . .
Page 6 and 7: wradlib Documentation, Release 0.1.
Page 68 and 69:
wradlib Documentation, Release 0.1.
Page 70 and 71:
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
show all

wradlib Documentation - Bitbucket

Create successful ePaper yourself

Delete template?

Save as template?