HDF5 information model and implementation specification for
weather radar data
Version 1.2
Daniel B. Michelson1 , Iwan Holleman2 , Harri Hohti3 , and Morten Salomonsen4
1
Swedish Meteorological and Hydrological Institute
2
Royal Netherlands Meteorological Institute
3
Finnish Meteorological Institute
4
Norwegian Meteorological Institute
COST 717 Working Document WDF_02_200204_1
February 13, 2003
Abstract
This document proposes an information model with which the encoding, decoding and management of data and products from weather radar systems may be facilitated. This information
model is based on the use of ordinary words to store data and header information; this strategy is
demonstrated as being more intuitive than the use of numerical descriptors, which leads to easier
data management. An implementation of this information model is also specified which makes
use of the HDF5 file format developed and maintained by the HDF Group at the National Centre
for Supercomputing Applications, University of Illinois at Urbana-Champaign. The result manifests itself in the form of truly self-describing weather radar data files highly suitable for environments where data exchange between radars from different manufacturers, different organizations,
and/or different countries is conducted. Reference to Nordic conditions is made throughout this
document, yet the implications for use are global.
HDF5 for weather radar data
i
Contents
1
Introduction and motivation
1.1 And why use HDF5? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2
Definitions
2.1 Scalars . . . . . . . . . . .
2.1.1 Sequences . . . . .
2.2 Attributes . . . . . . . . .
2.3 Datasets . . . . . . . . . .
2.4 Groups . . . . . . . . . . .
2.5 Information model concept
.
.
.
.
.
.
2
3
3
3
3
4
4
3
4
5
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Header attribute specification
3.1 Top-level what Group . . . . . . . . . . . . . . . . . . . .
3.2 where Group . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 where for polar data Groups . . . . . . . . . . . .
3.2.2 where for geographically referenced image Groups
3.2.3 where for cross-section data Group . . . . . . . .
3.2.4 where for vertical profiles . . . . . . . . . . . . .
3.2.5 where for vertical profile time series data Group .
3.3 how Group . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 what Group for Dataset objects . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
7
7
8
9
9
10
13
Data specification
4.1 Polar Data . . . . . . . . . . . . . .
4.2 Image Data . . . . . . . . . . . . .
4.3 RHIs, cross sections and side panels
4.4 Profiles . . . . . . . . . . . . . . .
4.5 Time series of vertical profiles . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
15
16
17
Example file structures
5.1 Polar volume . . . . . . . . . .
5.2 Geographically referenced image
5.3 Cross-section . . . . . . . . . .
5.4 Vertical profile . . . . . . . . .
5.5 Profile-time data . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
19
20
21
23
File naming conventions
.
.
.
.
.
.
.
.
.
.
24
COST 717 WDF_02_200204_1
HDF5 for weather radar data
ii
List of Tables
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Mandatory top-level what header Attributes for all weather radar files.
File object strings and their meanings . . . . . . . . . . . . . . . . . . . .
where Attributes for scan objects. . . . . . . . . . . . . . . . . . . .
where Attributes for geographical image data Groups . . . . . . . .
where Attributes for cross-section data. . . . . . . . . . . . . . . . .
where Attributes for vertical profiles. . . . . . . . . . . . . . . . . . .
where Attributes for THVP data. . . . . . . . . . . . . . . . . . . . .
how Attributes for all objects. . . . . . . . . . . . . . . . . . . . . . .
NORDRAD, DMI, and KNMI radar “places” and their node designations. .
Radar System abbreviations and their meanings . . . . . . . . . . . . . . .
Processing Software abbreviations and their meanings . . . . . . . . . . . .
Method abbreviations and their meanings . . . . . . . . . . . . . . . . . .
Dataset-specific what header Attributes. . . . . . . . . . . . . . . .
Product abbreviations and their meanings . . . . . . . . . . . . . . . . . .
Quantity (variable) identifiers. . . . . . . . . . . . . . . . . . . . . . . . .
Datasets for vertical profile files. . . . . . . . . . . . . . . . . . . . . . . .
Example polar volume file structure . . . . . . . . . . . . . . . . . . . . .
Example image product file structure . . . . . . . . . . . . . . . . . . . . .
Example cross-section file structure . . . . . . . . . . . . . . . . . . . . .
Example profile file structure . . . . . . . . . . . . . . . . . . . . . . . . .
Example profiles-time product file structure . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
7
8
8
9
9
10
11
12
12
13
13
14
14
16
17
19
20
21
23
COST 717 WDF_02_200204_1
HDF5 for weather radar data
1
1
Introduction and motivation
This document presents an information model developed for use with weather radar data and products.
Its implementation is also presented, which makes use of the Hierarchical Data Format version 5,
(HDF5). HDF5 is developed and maintained by the National Centre for Supercomputing Applications
(NCSA) at the University of Illinois at Urbana-Champaign1 . All references to attributes, data, types,
and so on, are in relation to those defined and used in the HDF5 documentation. The official HDF5
format documentation may be consulted for detail on the use of this format. Additionally, the HL-HDF
package, developed by SMHI, may be used along with its documentation 2 .
The information model given here is designed from the point of view of trying to keep all relevant
information from the three different radar manufacturers’ raw data, or polar volume data, presently in
use at the three institutes FMI, SMHI, and met.no. The exchange of polar volume data is aimed for
in such a way that each institute can use the exchanged data for generating products with the product
generation software supplied by their radar manufacturers. Use of a common data format throughout
the production chain simplifies management of both domestic and international networking.
At KNMI the operational infrastructure for the production and archiving of image data from satellites,
weather radars, and lightning detection systems will be replaced. A flexible and extendible file format
is needed to store the variety of data from these systems. Data from these systems will also be provided
to customers of KNMI in this (internal) file format. For both customers and users at KNMI, it is of
advantage when the number of different formats is limited and a variety of tools for data access and
viewing is freely available.
In both the Swedish network SWERAD and the Nordic network NORDRAD it is increasingly important to exchange data with higher quality and more quality-related information. Also, the operational
exchange of polar volumes internationally is expected with the introduction of a new software system for NORDRAD. This puts demands on the file format to be easy enough to extend and maintain
without the extensive effort of programmers to redesign the file format and its low level API. Use
of a proprietary format, such as one of those used by radar industry, is an unattractive solution since
each partner might have to pay license fees yet be unable to maintain the format themselves. Wellestablished non-proprietary formats such as HDF4 and netCDF are not as well designed as HDF5 for
our use, either due to their architectures or to lack of built-in compression.
Use of so-called “standard” meteorological formats (GRIB and BUFR) suffer from being subject to
tedious political and functional compromising, where the time from specification to official format
often takes several years. This procedure makes it slow and difficult to incorporate new technological
advances such as improved compression and storage of new types of data and quality-related information. While it is necessary to include the ability to import and export data in such formats, it would
be unwise to use one of them as the native format for use by modern systems.
Using a general-purpose, non-proprietary, Open Source, file format for our purposes offers several
major conceptual advantages over conventional industrial, proprietary, and even “standard” formats.
Open Source formats are most often developed by non-commercially oriented experts in the field with
the specific goal of creating a format which is general enough for most (e.g. scientific) purposes, high
1
2
Available at http://hdf.ncsa.uiuc.edu/HDF5/
Available at http://hdf.ncsa.uiuc.edu/tools5.html
COST 717 WDF_02_200204_1
HDF5 for weather radar data
2
performance, robust, and platform independent.
The organization also maintains and supports their format, in addition to their making all source
code, binaries, and documentation available for free. This makes such a format the most appropriate
conceptual solution, both within systems like SWERAD and outside it, since it offers the easiest
access of data to the users while the competency of the format developer insures that the format works
efficiently and securely in the real-time system environment.
1.1
And why use HDF5?
The basis of a file format is an information model and from the information model the file format’s API
is constructed. With HDF5 we already have an API interfacing with the HDF5 file format. So given
the information model, the need for a file API is reduced to creating a class, subroutine or function
interfacing with the HDF5 API, in effect a meta API, which is then used by the application implementing the information model. This is faster than using a conventional file format and will require
less effort and resources than the process of designing both the file format API and the application
using the API.
Compared to other formats, HDF5’s compression algorithm (ZLIB) is more efficient than NORDRAD’s and much more efficient than BUFR’s Run Length Encoding (RLE) algorithms. RLE is
reasonably efficient when the data set is mostly homogeneous, but less efficient with heterogeneous
data sets. Initial performance test results show that HDF5 is slower than the NORDRAD format, yet
faster than the BUFR-94 implementation using OPERA descriptors. HDF5 is faster than GRIB and
it has more efficient compression. Considering that we aim at exchanging polar volume data with
NORDRAD, a file format with efficient compression and platform independence is essential.
HDF5 is supported on a large number of Unix and Windows based platforms, and byte-order issues are
taken care of automatically. HDF5 files can easily be exchanged between different platforms. It can
also store data with most word types and depths. The format thus supports virtually any scientific data
with maximum flexibility, so operational exchange of, for example, 8-bit reflectivity, 16-bit spectral
width and/or 32-bit accumulated precipitation may be easily accommodated. Defining headers is
easily accomplished as well, which facilitates the definition of those attributes which are required
both now and in the future.
HDF5 is free, mature software from an organization with a proven track record. This means that
anyone has complete access to the source code and may develop/implement/maintain their applications themselves, easily following future modifications to the information model. This saves time and
money and gives the owner and user complete control over their own data.
2
Definitions
HDF5 allows data to be stored as Attributes, Datasets, Groups, and user-defined Compound
types. For use here, all types except user-defined Compound are permitted for use. In practice, all
of these types are manipulated through the use of general-purpose Node objects, i.e., a Node may be
any of the above mentioned types.
COST 717 WDF_02_200204_1
HDF5 for weather radar data
2.1
3
Scalars
Scalar values are stored in Attribute objects and may be any of the following, as defined in the
HDF5 documentation:
H5T_STD_I8BE, H5T_STD_I8LE, H5T_STD_I16BE, H5T_STD_I16LE,
H5T_STD_I32BE, H5T_STD_I32LE, H5T_STD_I64BE, H5T_STD_I64LE,
H5T_STD_U8BE, H5T_STD_U8LE, H5T_STD_U16BE, H5T_STD_U16LE,
H5T_STD_U32BE, H5T_STD_U32LE, H5T_STD_U64BE, H5T_STD_U64LE,
H5T_NATIVE_SCHAR, H5T_NATIVE_UCHAR, H5T_NATIVE_SHORT,
H5T_NATIVE_USHORT, H5T_NATIVE_INT, H5T_NATIVE_UINT,
H5T_NATIVE_LONG, H5T_NATIVE_ULONG, H5T_NATIVE_LLONG,
H5T_NATIVE_ULLONG, H5T_IEEE_F32BE, H5T_IEEE_F32LE,
H5T_IEEE_F64BE, H5T_IEEE_F64LE, H5T_NATIVE_FLOAT,
H5T_NATIVE_DOUBLE, H5T_NATIVE_LDOUBLE, H5T_STRING
In practice, this means that the native type on a given platform may be any of (pseudo-C syntax):
char, schar, uchar, short, ushort, int, uint, long, ulong, llong,
ullong, float, double, hsize, hssize, herr, hbool, string
It also means that a native type written on one platform will be read and automatically returned as the
corresponding native type on another platform.
Preferably, strings should be created using characters in the ISO-8859-1 character set, although support for UNICODE might be preferable in some circumstances.
2.1.1
Sequences
A special kind of string may be used to store sequences. A sequence contains comma-separated scalar
values in string notation. For example, a sequence is useful for storing the radar stations contributing
to a composite image, and in storing the elevation angles used in a polar volume of data.
2.2
Attributes
An Attribute is an HDF5 object used to store a header attribute or data. For our purposes, it is only
used to store header attributes. Note that the specification of strings is intended to be case sensitive.
2.3
Datasets
An HDF5 Dataset is a self-describing data object containing an n-dimensional array and attributes
describing it. The array type may be any of char, schar, uchar, short, ushort, int, uint,
long, ulong, llong, ullong, float, double on a given platform. The HL-HDF package
supports Datasets with up to four dimensions.
COST 717 WDF_02_200204_1
HDF5 for weather radar data
2.4
4
Groups
A Group is a top level object which is used to organize other objects. For example, a Group may
contain a collection of header Attributes, a collection of Datasets, or be the root object for the
complete contents of an HDF5 file.
2.5
Information model concept
The information model attempts to achieve a general-purpose model for storing both individual scans,
images and products, while also allowing series (time and/or space) of these types of information to
be stored using the same building-blocks. For example, an individual image product would have the
following structure:
/
/what
/where
/how
/image1
/image1/what
/image1/where
/image1/how
/image1/data
In this example, /image1/data is the actual Dataset object containing the product’s data.
A time series, for example, of such images would simply involve adding image1-imagen new
Groups.
Polar data works in the same way, with the exception that each scan is stored in a scan Group. Polar
volumes may be stored by collecting such scan Groups in the same way as images.
An important issue is understanding the relation between top level what, where and how and lower
level scan and image what, where and how. Attributes may be stored in one or both. Not all
Attributes need be stored in one or the other, so Attributes which do not change between data
objects may be stored at the top level, and Attributes that do change between data objects may be
stored at the lower levels. If a given Attribute appears both at the top and lower levels, then the
local level is the one that assumes precedence.
This concept allows for quite a bit of freedom and flexibility, so it is important that users exercise
good practice when making use of this information model.
COST 717 WDF_02_200204_1
HDF5 for weather radar data
3
5
Header attribute specification
Header attributes are collected in three Group objects, all of which may be used recursively.
Attributes which describe a given file’s contents and the time and place for which it represents are
collected in a Group called what. Attributes which describe a given file’s geographical characteristics (projection, corner coordinates, dimensions, scales) are collected in a Group called where.
The what and where Groups both contain mandatory Attributes only. Those Attributes
which collectively describe additional data/product characteristics, such as radar system, chosen algorithm, and quality-related information, are stored in a Group called how. All Attributes found
in how may be considered optional, although the use of those given in this document is highly recommended. Additional Attributes not specified in this document may only be stored in the how
Group.
Top-level header attributes are collected in what, where and how Group objects located directly
under the root Group ’/’. Each attribute is stored as an Attribute object containing a scalar value.
Some data/products may have Dataset-specific header attributes, in which case a the Dataset
and its header Attributes are collected in lower-level what, where and how Groups which are
associated with that Dataset.
The concept used here is that each Attribute is identified with a string, the idea being that this
is a more intuitive means of organizing data compared with numeric descriptors such as those used
by BUFR and GRIB. It also means that a file may be queried using the h5dump or hllist utilities
(equivalent of NORDRAD’s rr_head) to easily see and understand the contents of a file.
Mandatory header attributes for all files are given in Table 1. Note that all date and time information
is for the start of the volume scan according to OPERA3 recommendations.
Note that all geographical longitude/latitude coordinates are specified with positive easting values east
of the Greenwich meridian and positive northing values north of the equator.
3.1
Top-level what Group
In this section the content of the top-level what is described.
This Group contains mandatory Attributes only which collectively describe a given file’s contents and time of acquisition. These Attributes are given in Tables 1-14.
Table 1: Mandatory top-level what header Attributes for all
weather radar files.
Name
object
sets
Type
string
int
Format
-
Description
According to Table 2
The number of Datasets in the file. For vertical profiles, it’s the number of profiles in the file.
continued on next page
3
Operational Programme for the Exchange of Weather Radar Information. http://www.chmi.cz/OPERA/
COST 717 WDF_02_200204_1
HDF5 for weather radar data
6
continued from previous page
Name
version
Type
string
Format
H5rad M.m
date
time
string
string
YYYYMMDD
HHmmss
Description
Format or information model version. “M” is the major
version. “m” is the minor version. Software is encouraged to warn if it receives a file stored in a version which
is different from the one it expects. The software should,
however, proceed to read the file, ignoring Attributes
it does not understand.
Nominal Year, Month, and Day of the data/product
Nominal Hour, Minute, and Second, in UTC of the
data/product
Object strings may be any of those given in Table 2. For each Dataset, there may be an accompanying what Group with information specific to that Dataset, according to Table 13.
Table 2: File object strings and their meanings
String
PVOL
CVOL
SCAN
IMAGE
COMP
XSEC
VP
THVP
other
3.2
Description
Polar volume
Cartesian volume
Polar scan
2-D cartesian image
2-D cartesian composite image
2-D vertical cross section
1-D vertical profile
Time series of 1-D vertical profiles
User-defined
where Group
In this section the Attributes for the where Group are described. These are different for polar
or cartesian Datasets, i.e. containing scan and image Groups respectively.
Note that the use of the where Group is mandatory but that its placement may be either at the top
level of a given file, or at a lower level associated with a given Dataset. If where is found at the
top level, then it is assumed that its contents apply to all Datasets in the file. If where is found
at a lower level, then it must be located in a scan or image Group to which its contents apply.
If where exists at both the top and lower levels, then the contents of the local where override the
contents of the top level where.
Note as well that there can often be cases where some Attributes apply for all Datasets in a
file and others may be different for each Dataset. In such cases, the Attributes which apply to
all Datasets may be held in a top level where Group and those that change may be held in local
where Groups.
COST 717 WDF_02_200204_1
HDF5 for weather radar data
3.2.1
7
where for polar data Groups
This where Group contains mandatory Attributes only which collectively describe geographical
and geometrical characteristics of a given scan Dataset. Note that the Dataset itself is the object
containing the binary data and that where in this context describes that Dataset but is not actually
part of that Dataset. Section 2.5 illustrates how these two objects are related to each other.
Polar data, i.e. raw radar data as a function of azimuth and range, are stored in a scan Group,
and polar volume data are stored as a stack of these scan Groups. Each scan Group contains
azimuthal data from a single elevation and a single quantity.
Table 3: where Attributes for scan objects.
3.2.2
Name
lon
Type
float
lat
float
height
angle
xsize
ysize
xscale
float
float
int
int
float
Description
Longitude position of the radar antenna (degrees). Fractions of a degree are given in decimal notation.
Latitude position of the radar antenna (degrees). Fractions of a degree
are given in decimal notation.
Height of the centre of the antenna in meters above sea level.
Antenna elevation angle (degrees) above the horizon.
Number of range bins in each ray
Number of azimuth gates (rays) per scan
The distance in meters between two successive range bins
where for geographically referenced image Groups
This where Group contains mandatory Attributes only which collectively describe a given
image’s geographical and geometrical characteristics. Note that the Dataset itself is the object
containing the binary data and that where in this context describes that Dataset but is not actually
part of that Dataset. Section 2.5 illustrates how these two objects are related to each other.
The PROJ4 cartographic projections library from the United States Geological Survey 4 is an easy
and comprehensive means of managing geographically referenced information. PROJ4 is being used
increasingly in Sweden, the Nordic countries, and Europe. As a result, the most straight-forward
way of representing projection information in radar files is by means of the projection definition
string which is used with the library itself. For example, in a Swedish composite product, the Polar
Stereographic projection may be used with a spherical earth model (radius 6376177 m) and an origin
at 60◦ N and 14◦ E. The arguments used with PROJ4 to define this projection are +proj=stere
+a=6376177 +lat_0=90 +lon_0=14 +lat_ts=60 so this is what should be found as an
Attribute in the where Group associated with the Dataset used to store the composite data.
Note that USGS PROJ4 contains a complete set of arguments for specifying a given projection, including false easting/northing, rescaling of coordinates, choice of ellipsoid (or defining your own),
and defining oblique (rotated) projections.
4
ftp://kai.er.usgs.gov/pub/Proj.4/
COST 717 WDF_02_200204_1
HDF5 for weather radar data
8
Table 4: where Attributes for geographical image data
Groups
3.2.3
Name
projdef
Type
string
xsize
ysize
xscale
int
int
float
yscale
float
LL_lon
LL_lat
UR_lon
UR_lat
float
float
float
float
Description
The projection definition arguments, described on page 7, which can
be used with USGS PROJ4. See the PROJ4 documentation for usage
Number of pixels in the X dimension
Number of pixels in the Y dimension
Pizel size in the X dimension, in projection-specific coordinates (often
meters)
Pixel size in the Y dimension, in projection-specific coordinates (often
meters)
Longitude of the lower left pixel corner (OPERA recommendation)
Latitude of the lower left pixel corner (OPERA recommendation)
Longitude of the upper right pixel corner (OPERA recommendation)
Latitude of the upper right pixel corner (OPERA recommendation)
where for cross-section data Group
RHI and cross-sections are treated as a special form of cartesian images. The x-dimension of the
image represents the coordinate in the x/y-plane, while the y-dimension describes the vertical coordinate of the RHI or cross-section. To describe the geographical orientation and extend of a RHI or
cross-section a dedicated set of Attributes in the where Group has been defined. The geographical location of cross-sections is just given by longitudes and latitudes of start and stop positions.
The cross-sections are thus assumed to be taken along great-circles. In case they are taken along a
line in a plane of a geographical projection the deviation from the great-circle will be negligible for
visualization purposes.
Table 5: where Attributes for cross-section data.
Name
Type Description
Common attributes
xsize
int
Number of pixels in the horizontal dimension
ysize
int
Number of pixels in the vertical dimension
xscale
float Horizontal resolution in m
yscale
float Vertical resolution in m
RHI specific
lon
float Longitude position of the radar antenna (degrees). Fractions of a degree are given in decimal notation.
lat
float Latitude position of the radar antenna (degrees). Fractions of a degree
are given in decimal notation.
az_angle float Azimuth angle
range
float Maximum range in km
Cross section and side panel specific
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
9
continued from previous = page
Name
start_lon
start_lat
stop_lon
stop_lat
3.2.4
Type
float
float
float
float
Description
Start position’s longitude
Start position’s latitude
Stop position’s longitude
Stop position’s latitude
where for vertical profiles
This where Group contains mandatory Attributes only which collectively describe the geographical and geometrical characteristics of vertical profiles of horizontal winds and/or radar reflectivity.
Table 6: where Attributes for vertical profiles.
3.2.5
Name
lon
Type
float
lat
float
height
levels
interval
float
int
float
Description
Longitude position of the radar antenna (degrees). Fractions of a degree are given in decimal notation.
Latitude position of the radar antenna (degrees). Fractions of a degree
are given in decimal notation.
Height of the centre of the antenna in meters above sea level.
Number of points in the profile
Vertical distance (m) between height intervals, or 0.0 if variable
where for vertical profile time series data Group
Time series of vertical profiles are treated as a special kind of cartesian image. The x-dimension of
the image represents the time coordinate, while the y-dimension describes the vertical coordinate of
the profiles. The vertical profiles should be available with equidistant vertical levels and constant time
intervals. In absence of data at a certain level or for a certain time, the corresponding areas should
be filled with the “nodata” value. To describe the geographical location, the height levels, and the
time axis of the profile’s time series, a dedicated set of Attributes in the where Group has been
defined. Each THVP Dataset contains a single quantity. For wind profiles the THVP file will
contain at least two Datasets: one for the u-component and one for the v-component of the wind
field.
Table 7: where Attributes for THVP data.
Name Type Description
Common attributes
lon
float Longitude position of the radar antenna (degrees). Fractions of a degree are given in decimal notation.
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
10
continued from previous = page
3.3
Name
lat
Type
float
height
xsize
ysize
xscale
yscale
xoffset
float
int
int
float
float
float
yoffset
float
Description
Latitude position of the radar antenna (degrees). Fractions of a degree
are given in decimal notation.
Height of the centre of the antenna in meters above sea level.
Number of pixels on the time axis
Number of pixels in the vertical dimension
Time resolution in seconds
Vertical resolution in m
Time (UTC) of first profile/column in seconds after 00:00 UTC on the
day defined by the “date” Attribute in the what Group
Height of first level of profile in m
how Group
This Group contains recommended and other Attributes which provide additional and complimentary information which can be used to describe a given scan or image object, for example
information related to an object’s quality.
Note that the use of the how Group is optional and that its placement may be either at the top level
of a given file, or at a lower level associated with a given Dataset. If how is found at the top level,
then it is assumed that its contents apply to all Datasets in the file. If how is found at a lower level,
then it must be located in a scan or image Group to which its contents apply. If how exists at both
the top and lower levels, then the contents of the local how override the contents of the top level how.
Note as well that there can often be cases where some Attributes apply for all Datasets in a file
and others may be different for each Dataset. In such cases, the Attrs which apply to all Datasets
may be held in a top level where Group and those that change may be held in local where Groups.
For clarity, Table 8 containing recommended how Attributes is partitioned such that different
partitions contain different product-specific Attributes.
Table 8: how Attributes for all objects.
Name
Type
Description
General
WMO
place
int
string
Combined WMO block and station number or 0 if none assigned
Area identifier, e.g. according to table 9 or sswe for a regional
Swedish composite
Seconds after a standard 1970 epoch for which the starting time of the
data/product is valid. A compliment to “date” and “time” in Table 1.
Seconds after a standard 1970 epoch for which the ending time of the
data/product is valid. A compliment to “date” and “time” in Table 1.
According to Table 10
According to Table 11
startepochs
int
endepochs
int
system
software
string
string
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
11
continued from previous page
Name
zr_a
Type
float
Description
Z-R constant A in Z = A Rb , applicable to any product containing
reflectivity or precipitation intensity
zr_b
float
Z-R exponent b in Z = A Rb , applicable to any product containing
reflectivity or precipitation intensity
Data from individual radars
beamwidth
float
The radar’s half-power beamwidth (degrees)
wavelength
float
Wavelength in cm
rpm
float
The antenna speed in revolutions per minute
pulsewidth
float
Pulse width in µs
lowprf
int
Low pulse repetition frequency in Hz
highprf
int
High pulse repetition frequency in Hz
angles
sequence Elevation angles used when creating product
Polar data
azmethod
string
How raw data in azimuth are processed to arrive at the given value,
according to Table 12
binmethod
string
How raw data in range are processed to arrive at the given value, according to Table 12
Cartesian images including composites
angles
sequence Elevation angles in ascending order (OPERA recommendation), used
to generate the product
camethod
string
How cartesian data are processed, according to Table 12
nodes
sequence Radar nodes (Table 9) which have contributed data to the composite,
e.g. “’gbg’, ’osl’, ’cph’, ’kor”’
Vertical profile specific
minrange
float
Minimum range at which data is used when generating profile (km)
maxrange
float
Maximum range at which data is used when generating profile (km)
NI
float
Unambiguous velocity (Nyquist) interval (±m/s)
dealiased
int
1 if data has been dealiased, 0 if not
Table 9: NORDRAD, DMI, and KNMI radar “places” and their
node designations. The use of three-letter nodes makes it possible
to represent up to 17 576 radars if non-accented lettering is used.
The “place” name may use UNICODE characters
Place
Hægebostad
Oslo
Kiruna
Luleå
Örnsköldsvik
Östersund
Hudiksvall
Leksand
Node
hgb
osl
kir
lul
ovi
osu
hud
lek
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
12
continued from previous page
Place
Arlanda
Norrköping
Vara
Hemse
Karlskrona
Ängelholm
Korpo
Vantaa
Anjalankoski
Ikaalinen
Kuopio
Utajärvi
Luosto
Stevns
Sindal
Rømø
De Bilt
Den Helder
Node
arl
nkp
var
hem
kkr
ang
kor
van
anj
ika
kuo
uta
luo
ste
sin
rom
blt
dhl
Table 10: Radar System abbreviations and their meanings
String
GEMAxxx
EECxxx
ERICxxx
other
Meaning
Gematronik Meteor ACxxx Radar
EEC xxx Radar
Ericsson xxx Radar
other
Table 11: Processing Software abbreviations and their meanings
String
IRIS
EDGE
EWIS
RAINBOW
FROG
SWERAD
NORDRAD
RMV
other
Meaning
Sigmet IRIS
EEC Edge
Ericsson EWIS
Gematronik Rainbow
Gamic FROG, MURAN . . .
SWERAD
NORDRAD
DWD RMV
other
COST 717 WDF_02_200204_1
HDF5 for weather radar data
13
Table 12: Method abbreviations and their meanings
String
NEAREST
INTERPOL
AVERAGE
RANDOM
MDE
LATEST
MAXIMUM
DOMAIN
VAD
VVP
RGA
other
3.4
Meaning
Nearest neighbour or closest radar
Interpolation
Average of all values
Random
Minimum distance to earth
Most recent radar
Maximum value
User-defined compositing
Velocity azimuth display
Volume velocity processing
Gauge-adjustment
Experimental
what Group for Dataset objects
In this section the content of the what Group to be used with each Dataset is described. Note that
the linear transformation coefficients “gain” and “offset” should be set to 1 and 0 respectively if they
are not intended for use with a given Dataset.
Table 13: Dataset-specific what header Attributes.
Name
product
prodpar
Type
string
float
Format
-
quantity
string
-
startdate
starttime
enddate
endtime
string
string
string
string
Starting YYYYMMDD
Starting HHmmss
Ending YYYYMMDD
Ending HHmmss
gain
offset
nodata
float
float
float
-
Description
According to Table 14
Product parameter, i.e., height for CAPPI-based products (meters above the radar), elevation (degrees) for PPI, reflectivity level
(dBZ) for echo tops, integration period (hours) for precipitation
accumulation, azimuth (degrees) for RHI. For VIL, two values
are stored in a SIMPLE array: the bottom and top heights (m) of
the integration layer.
According to Table 15
Year, Month, and Day for the product
Hour, Minute, and Second for the product
Year, Month, and Day for the product
Hour, Minute, and Second for the product
Coefficient ’a’ in y=ax+b used to convert int to float
Coefficient ’b’ in y=ax+b used to convert int to float
Raw value used to denote areas void of data (never radiated).
Note that this Attribute is always a float even if the data in
question is in another format.
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
14
continued from previous page
Name
undetect
Type
float
Format
-
Description
Raw value used to denote areas below the measurement detection threshold (radiated but nothing detected). Note that this
Attribute is always a float even if the data in question is in
another format.
Table 14: Product abbreviations and their meanings
String
SCAN
PPI
CAPPI
PCAPPI
ETOP
ZMAX
RR
VIL
COMP
WRWP
RHI
XSEC
VSP
HSP
other
Meaning
A scan of polar data
Plan position indicator
Constant altitude PPI
Pseudo-CAPPI
Echo top
Maximum reflectivity
Accumulation
Vertically integrated liquid water
Composite
Wind profile
Range height indicator
Arbitrary vertical slice
Vertical side panel
Horizontal side panel
Experimental
Table 15: Quantity (variable) identifiers.
String
DBZ
LZDR
RATE
ACRR
HGHT
VIL
VRAD
WRAD
UWND
VWND
BRDR
Quantity [Unit]
Z [dBZ]
ZDR [dBZ]
RR [mm/h]
RRaccum. [mm]
H [km]
VIL [kg/m2 ]
Vrad [m/s]
Wrad [m/s]
U [m/s]
V [m/s]
0 or 1
QIDX
Quality [0-1]
Description
Logged reflectivity factor
Logged differential reflectivity factor
Rain rate
Accumulated precipitation
Height (of echotops)
Vertical Integrated Liquid water
Radial velocity
Spectral width of radial velocity
Component of wind in x-direction
Component of wind in y-direction
1 denotes a border where data from two or more radars meet in
composites, otherwise 0
A spatially analyzed quality weight index ranging from 0 (poorest) to 1 (best).
COST 717 WDF_02_200204_1
HDF5 for weather radar data
4
15
Data specification
All data arrays, both for polar and cartesian data, are stored as Dataset objects. Any of compression levels 1 to 6 are recommended. (HDF5’s built-in compression levels range from 0 (none) to 9
(maximum); levels above 6 tend to result in the algorithm using disproportionate resources relative to
gains in file size, which is why their use is not encouraged.) Examples of how Datasets and header
attributes are managed in HDF5 files are provided in Section 5.
4.1
Polar Data
Each scan in a polar volume file is contained in a Group denoted scann, where n is the scan index
in ascending order starting at 1. One variable only is represented in each scan Dataset. The
Attributes used to describe the characteristics of the data are contained in the Group’s what,
where and how Groups. The data itself is stored in a self-contained HDF5 Dataset.
The start of the first azimuth gate (the first pulse) always points due north and the first range bin is
that starting at the radar. This implies that the first azimuth gate covers the interval 0-1 ◦ assuming 360
azimuth gates per scan. Azimuth gates are ordered clockwise. In other words, range bins are stored
in the array’s equivalent X-dimension and azimuth gates in the Y-dimension. There is no mechanism
for specifying missing azimuth gates or range bins. This means that partial scans/rays must be filledin in order to complete them. Filled-in areas are identified by the “nodata” value specified in the
corresponding what Group.
4.2
Image Data
An image product in this context refers to 2-D cartesian quantitative data and not a visual graphic product. Each image is contained in a Group denoted imagen, where n is the layer index, in ascending
order where applicable, starting at 1. One variable only is represented in each image Dataset. The
Attributes used to describe the characteristics of the data are contained in the Group’s what,
where and how Groups. The data itself is stored in a self-contained HDF5 Dataset.
Binary arrays are ordered stored as one long unpadded binary string starting in the upper-left corner
and proceeding row by row (north to south), from left (west) to right (east). Areas void of the specified
variable are flagged using the “nodata” value specified in the corresponding what Group.
4.3
RHIs, cross sections and side panels
RHI, cross sections and side panels are a special form of image. RHIs taken with the antenna pointing
east start on the left and end on the right. If the antenna points west, then the RHI starts on the right
and ends on the left. RHIs pointing exactly south or north always start on the left and end on the right.
For cross sections, the left side of the image is the starting point and the right side is the finishing
point, regardless of the antenna’s azimuth angle. For side panels, the starting point is north for vertical
COST 717 WDF_02_200204_1
HDF5 for weather radar data
16
panels and west for horizontal panels. As with other image files, the first pixel is the upper-left one
and image content is ordered row-wise from top to bottom and left to right.
4.4
Profiles
In contrast to polar or cartesian data which use Datasets to store 2-D arrays, profiles use several
Datasets to store 1-D arrays representing different variables along a given profile. One variable is
stored in each Dataset. Levels in the profile are ordered sequentially in ascending order. A profile
is a Group called profilen containing several Datasets, each of which stores a variable for that
level.
At each profile, mandatory Datasets are specified in Table 16.
Table 16: Datasets for vertical profile files.
Name
Type Description
Mandatory
height
float Mean height of the level (m a s l)
Optional (recommended)
ff
float Mean horizontal wind velocity (m/s)
dd
float Mean horizontal wind direction (degrees)
ff_dev
float Velocity variability (m/s)
dd_dev
float Direction variability (m/s)
n
int
Sample size
dbz
float Logged radar reflectivity factor (dBZ)
dbz_dev float Variability of logged radar reflectivity factor (dBZ)
z
float Linear radar reflectivity factor (Z)
z_dev
float Variability of linear radar reflectivity factor (Z)
w
float Vertical velocity (m/s, positive upwards)
w_dev
float Vertical velocity variability (m/s)
div
float Divergence (s−1 )
div_dev float Divergence variation (s−1 )
def
float Deformation (s−1 )
def_dev float Deformation variation (s−1 )
ad
float Axis of dialation (0-360◦ )
ad_dev
float Variability of axis of dialation (0-360◦ )
chi2
float Chi-square value of wind profile fit
Note that all Datasets must be of equal length, in order to match the heights given in height.
Also, care should be taken in defining “nodata” and “undetect” Attributes, since these will be
applicable to all Dataset in the profile. It might therefore be advisable to use “conventional” meteorological flags such as -9999, for these purposes.
This way of storing vertical profiles can be used with time series of such profiles as well, but there is
a more efficient way of doing this which is specified in the next section.
COST 717 WDF_02_200204_1
HDF5 for weather radar data
4.5
17
Time series of vertical profiles
Time series of vertical profiles are treated as a special kind of cartesian images. The x-dimension of
the image represents the time coordinate, while the y-dimension describes the vertical coordinate of
the profiles. The vertical profiles should be available with equidistant vertical levels and constant time
intervals. In absence of data at a certain level or for a certain time, the corresponding areas should
be filled with the “nodata” value. As with other image files, the first pixel is the upper-left one, i.e.
the maximum height level of the first profile, and the image content is ordered row-wise from top to
bottom and left to right, i.e. from first profile to last profile in time series. This implies that the height
increment (“yscale”) will be negative! Each profile-time image Dataset contains a single quantity.
For wind profiles the profile-time file will contains at least two Datasets: one for the u-component
and one for the v-component of the wind field.
5
Example file structures
The following examples show how attributes and data are structured in different types of files. The
structure is very similar to that of a computer file system, which is why the “H” in HDF stands for
“hierarchy”.
Note that these examples do not show all the possibilities of storing weather radar data using this
information model, but only selected cases of good practice.
The identifier column shows the identifier strings exactly as they would be used in real applications.
In other words, when reading a given Attribute or Dataset, the user would provide the identifier
string as an argument and the Attribute or Dataset would be returned. Keep in mind that the
contents of a Group must be written to file together and that the Group itself must be defined before
its contents; otherwise the HDF5 software will crash. However, objects can be read in any arbitrary
order.
5.1
Polar volume
Table 17: Example polar volume file structure
Identifier
/
/what
/what/object
/what/sets
/what/version
/what/date
/what/time
/where
/where/lon
Value
PVOL
2
H5rad 1.2
20020318
064500
16.152
Description
Root Group
Top level what Group
A polar volume
Two Datasets in this file
This information model version
Date
Time
Top level where Group
Radar’s longitude position
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
18
continued from previous page
Identifier
/where/lat
/where/height
/where/xsize
/where/ysize
/how
/how/WMO
/how/place
/how/system
/how/software
/how/beamwidth
/how/wavelength
/scan1
/scan1/what
/scan1/what/product
/scan1/what/prodpar
/scan1/what/quantity
/scan1/what/startdate
/scan1/what/enddate
/scan1/what/starttime
/scan1/what/endtime
/scan1/what/gain
/scan1/what/offset
/scan1/what/nodata
/scan1/what/undetect
/scan1/where
/scan1/where/angle
/scan1/where/xscale
/scan1/how
/scan1/how/rpm
/scan1/how/startepochs
/scan1/how/endepochs
/scan1/how/pulsewidth
/scan1/how/lowprf
/scan1/how/highprf
/scan1/how/azmethod
Value
58.583
57.0
120
420
2570
Norrköping
ERIC
SWERAD
0.9
5.35
SCAN
0.5
DBZ
20020318
20020318
064500
064510
0.4
-30.0
255.0
0.0
0.5
2.0
6.0
1016430300.0
1016430310.0
2.0
250
250
RANDOM
/scan1/how/binmethod
/scan1/data
AVERAGE
Dataset
/scan2
/scan2/what
/scan2/what/product
/scan2/what/prodpar
/scan2/what/quantity
SCAN
1.2
VRAD
Description
Radar’s latitude position
Radar’s height above sea level
Range bins per azimuth gate
Azimuth gates per scan
Top level how Group
WMO block and station number
Radar’s location
Ericsson radar
SWERAD-specific software
Beamwidth
Wavelength in cm
Group containing a scan object
what for this scan
A scan of polar data
The scan’s elevation angle
Z (dBZ) data
Start date
End date
Start time
End time
’a’ in dbz = a×raw+b
’b’ in dbz = a×raw+b
Areas never radiated
Areas below detection threshold
where for this scan
Elevation angle for this scan
2 km range bins
how for this scan
Antenna speed in rpm
Start time in epoch seconds
End time in epoch seconds
µs
Low PRF in Hz
No dual PRF
Ericsson uses only one pulse in non-Doppler
mode
Range bins are averaged
Binary Dataset containing radar reflectivity
factor data
Group containing the next scan object
what for this scan
Another scan of polar data
The scan’s elevation angle
Radial velocity this time
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
19
continued from previous page
Identifier
/scan2/what/startdate
/scan2/what/enddate
/scan2/what/starttime
/scan2/what/endtime
/scan2/what/gain
/scan2/what/offset
/scan2/what/nodata
/scan2/what/undetect
/scan2/where
/scan2/where/angle
/scan2/where/xscale
/scan2/how
/scan2/how/rpm
/scan2/how/startepochs
/scan2/how/endepochs
/scan2/how/pulsewidth
/scan2/how/lowprf
/scan2/how/highprf
/scan2/how/azmethod
/scan2/how/binmethod
/scan2/data
5.2
Value
20020318
20020318
064515
064545
0.375
-48.0
255.0
0.0
1.2
1.0
2.0
1016430315.0
1016430345.0
0.5
900
1200
AVERAGE
AVERAGE
Dataset
Description
Start date
End date
Start time
End time
’a’ in vrad = a×raw+b
’b’ in vrad = a×raw+b
Areas never radiated
Areas below detection threshold
where for this scan
Elevation angle for this scan
1 km range bins
how for this scan
Antenna speed in rpm
Start time in epoch seconds
End time in epoch seconds
µs
Low PRF in Hz
High PRF in Hz
Ericsson averages pulses in Doppler
Range bins are averaged
Binary Dataset
Geographically referenced image
Table 18: Example image product file structure
Identifier
/
/what
/what/object
/what/sets
/what/version
/what/date
/what/time
/where
/where/projdef
/where/xsize
/where/ysize
Type
COMP
2
H5rad 1.2
20020318
064500
+proj=stere
+a=6376177
+lat_0=90
+lon_0=14
+lat_ts=60
512
512
Description
Root Group
Top level what Group
A cartesian composite image
Two Datasets in this file
This information model version
Date
Time
Top level where Group
USGS PROJ4 string used to define the used
projection
Columns
Rows
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
20
continued from previous page
Name
/where/xscale
/where/yscale
/where/LL_lon
/where/LL_lat
/where/UR_lon
/where/UR_lat
/how
/how/place
/how/software
/how/camethod
/how/nodes
/image1
/image1/what
/image1/what/product
/image1/what/prodpar
/image1/what/quantity
/image1/what/gain
/image1/what/offset
/image1/what/nodata
/image1/what/undetect
/image1/data
/image2
/image2/what
/image2/what/product
/image2/what/prodpar
/image2/what/quantity
/image2/what/gain
/image2/what/offset
/image2/what/nodata
Type
2.0
2.0
8.212
53.184
26.065
61.853
sswe
NORDRAD
MDE
’ang’,
’kkr’,
’hem’, ’gbg’,
’nkp’, ’arl’
PCAPPI
500
DBZ
0.4
-30.0
255.0
0.0
Dataset
COMP
500
BRDR
1.0
0.0
255.0
/image2/what/undetect
/image2/data
0.0
Dataset
5.3
Description
2 km east-west resolution
2 km north-south resolution
South-west corner longitude
South-west corner latitude
North-east corner longitude
North-east corner latitude
Top-level how Group
Regional Swedish composite
NORDRAD system generated this composite
NORDRAD’s compositing algorithm
Radars available for this composite
Group containing an image object
what for this image
A composite image
Based on 500 m Pseudo-CAPPI products
Z (dBZ) data
’a’ in dbz = a×raw+b
’b’ in dbz = a×raw+b
Uncovered areas
Areas void of detectable DBZ data
Binary Dataset
Group containing an image object
what for this image, in this case a bitmap
A composite image, sort-of
Based on 500 m Pseudo-CAPPI products
Border bitmap
no need to re-scale
no need to re-scale
Areas void of BRDR data (not actually
needed)
(not actually needed either)
Binary Dataset
Cross-section
Table 19: Example cross-section file structure
Identifier
/
/what
/what/object
Value
XSEC
Description
Root Group
Top level what Group
A cross section
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
21
continued from previous page
Identifier
/what/sets
/what/version
/what/date
/what/time
/where
/where/xsize
/where/ysize
/where/xscale
/where/yscale
/where/start_lon
/where/start_lat
/where/stop_lon
/where/stop_lat
/how
/how/WMO
/how/place
/how/system
/how/software
/how/beamwidth
/how/wavelength
/image1
/image1/what
/image1/what/product
/image1/what/prodpar
/image1/what/quantity
/image1/what/gain
/image1/what/offset
/image1/what/nodata
/image1/what/undetect
/image1/data
5.4
Value
1
H5rad 1.2
20020318
064500
222
41
500.0
200.0
16.0
58.0
16.0
59.0
2570
Norrköping
ERIC
SWERAD
0.9
5.35
XSEC
DBZ
0.4
-30.0
255.0
0.0
Dataset
Description
One Dataset in this file
This information model version
Date
Time
Top level where Group
Number of pixels in horizontal direction
Number of pixels in vertical direction
Horizontal resolution in m
Vertical resolution in m
Start position’s longitude
Start position’s latitude
Stop position’s longitude
Stop position’s latitude
Top level how Group
WMO block and station number
Radar’s location
Ericsson radar
SWERAD-specific software
Beamwidth
Wavelength in cm
Group containing a scan object
what for this scan
A cross-section through a volume file
No specific product parameter
Z (dBZ) data
’a’ in dbz = a×raw+b
’b’ in dbz = a×raw+b
Unradiated areas
Areas with no detectable data
Binary array containing radar reflectivity factor
data
Vertical profile
Table 20: Example profile file structure
Identifier
/
/what
/what/object
/what/sets
/what/version
Value
VP
2
H5rad 1.2
Description
Root Group
Top level what Group
A vertical profile
Two profiles in this file
This information model version
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
22
continued from previous page
Identifier
/what/date
/what/time
/what/nodata
/what/undetect
/where
/where/lon
/where/lat
/where/height
/where/levels
/where/interval
/how
/how/WMO
/how/place
/how/system
/how/software
/how/beamwidth
/how/wavelength
/how/rpm
/how/pulsewidth
/how/lowprf
/how/highprf
/how/azmethod
/how/binmethod
/how/angles
/how/maxrange
/how/NI
/how/dealiased
/profile1
/profile1/what
/profile2/what/time
/profile1/height
/profile1/ff
/profile1/dd
/profile1/dbz
/profile1/n
/profile2
/profile2/what
/profile2/what/time
/profile2/height
/profile2/ff
/profile2/dd
/profile2/dbz
/profile2/n
Value
20020318
064500
-9999.0
-9998.0
16.152
58.583
57.0
3
0.0
2570
Norrköping
ERIC
SWERAD
0.9
5.35
2.0
0.5
900
1200
AVERAGE
AVERAGE
0.5,0.9,1.3
25.0
48.0
0
064500
Dataset
Dataset
Dataset
Dataset
Dataset
070000
Dataset
Dataset
Dataset
Dataset
Dataset
Description
Date
Time
Unradiated areas
Radiated areas below detection threshold
Top level where Group
Radar’s longitude position
Radar’s latitude position
Radar’s height above sea level
Number of points along the profile
Variable vertical distance along the profile
Top-level how Group
WMO block and station number
Radar’s location
Ericsson radar
SWERAD-specific software
Beamwidth
Wavelength in cm
Antenna speed in rpm
µs
Low PRF in Hz
High PRF in Hz
Ericsson averages pulses in Doppler
Range bins are averaged
Elevation angles used
Data used out to 25 km
Pretty big unambiguous velocity interval
Data outside NI are wrapped
Group holding the first profile in the file
what for this profile
The nominal time for this profile
Height array
Velocity array
Direction array
Reflectivity factor array
Sample size array
Group holding the second profile in the file
what for this profile
The nominal time for this profile
Height array
Velocity array
Direction array
Reflectivity factor array
Sample size array
COST 717 WDF_02_200204_1
HDF5 for weather radar data
5.5
23
Profile-time data
Table 21: Example profiles-time product file structure
Identifier
/
/what
/what/object
/what/sets
/what/version
/what/date
/what/time
/what/startdate
/what/starttime
/what/enddate
/what/endtime
/where
/where/lon
/where/lat
/where/height
/where/xsize
/where/ysize
/where/xscale
/where/yscale
Type
THVP
3
H5rad 1.2
20020318
064500
20020317
180000
20020318
060000
5.179
52.102
45.0
96
41
900.0
-200.0
/where/xoffset
/where/yoffset
/how
/how/place
/how/software
/image1
/image1/what
/image1/what/product
/image1/what/prodpar
/image1/what/quantity
/image1/what/gain
/image1/what/offset
/image1/what/nodata
/image1/what/undetect
/image1/data
/image2
/image2/what
/image2/what/product
/image2/what/prodpar
/image2/what/quantity
/image2/what/gain
0.0
8000.0
blt
RAINBOW
WRWP
UWND
0.3
-38.0
255.0
-9999.0
Dataset
WRWP
VWND
0.3
Description
Root Group
Top level what Group
A time series of 1-D vertical profiles
Three Datasets in this file
This information model version
Nominal date of the product
Nominal time of the product
First profile’s date
First profile’s time
Last profile’s date
Last profile’s time
Top level where Group
Radar’s longitude position
Radar’s latitude position
Radar’s height above sea level
Columns / time points
Rows / height levels
A vertical profile every 15 minutes
Height difference between successive levels
in m
First profile at midnight, 0 seconds offset
Maximum height of profile, 8 km
Top-level how Group
KNMI radar in De Bilt
Rainbow software generated the profiles
Group containing an image object
what for this image
Wind profiles
No specific product parameter
U-wind component data
’a’ in u-wind = a×raw+b
’b’ in u-wind = a×raw+b
Unradiated areas
Areas void of u-wind data
Binary array
Group containing an image object
what for this image
Wind profiles
No specific product parameter
V-wind component data
’a’ in v-wind = a×raw+b
continued on next page
COST 717 WDF_02_200204_1
HDF5 for weather radar data
24
continued from previous page
Name
/image2/what/offset
/image2/what/nodata
/image2/what/undetect
/image2/data
/image3
/image3/what
/image3/what/product
/image3/what/prodpar
/image3/what/quantity
/image3/what/gain
/image3/what/offset
/image3/what/nodata
/image3/what/undetect
/image3/data
6
Type
-38.0
255.0
-9999.0
Dataset
WRWP
DBZ
0.5
-31.5
255.0
0.0
Dataset
Description
’b’ in v-wind = a×raw+b
Unradiated areas
Areas void of v-wind data
Binary array
Group containing an image object
what for this image
Wind profiles
No specific product parameter
Z (dBZ) data
’a’ in dbz = a×raw+b
’b’ in dbz = a×raw+b
Unradiated areas
Areas void of DBZ data
Binary array
File naming conventions
File strings describe (in as much detail as possible without being difficult to manage) the file’s contents, reflecting what kind of data or product, from which radar (if not a composite), and from which
date and time the information stored in it originates.
File strings must be designed such that they are supported by most commonly used operating systems
like various dialects of Unix, Windows, MacOS, and possibly VMS/OpenVMS. MS DOS 8.3 file
naming constraints, like DOS itself, should be avoided . . .
COST 717 WDF_02_200204_1