View
220
Download
2
Category
Preview:
Citation preview
1
Report on radar-based products developed in the frame of BALTRAD+ WP4
Authors:
Jan Szturc, Katarzyna Osródka, and Anna Jurczyk (IMGW), Harri Hohti, Joonas Karjalainen, and Jarmo Koistinen (FMI), Günther Haase and Daniel Michelson (SMHI), Rashpal S. Gill and Martin B. Sørensen (DMI), Juhani Lahtinen and Tuomas Peltonen (STUK),
and other BALTRAD+ Project Partners Date: January 2014 BALTRAD Document: BALTRAD+ W4-42
Part-financed by the European Union (European Regional Development Fund and European Neighbourhood Partnership Instrument
2
Contents
1. Motivation . . . . . . . . . . 3
2. BALTRAD+ products classification . . . . . . 3
3. Catalogue of 2D products . . . . . . . . 4
3.1. Plan Position Indicator . . . . . . . . 4
3.1.1. Quality-based PPI (Plan Position Indicator) product generation – Product2D: PPI . 4
3.2. Constant altitude PPI . . . . . . . . 8
3.2.1. RAVE-incorporated algorithm (3PMAX composite generation) . . . 8
3.3. Range height indicator . . . . . . . . 8
3.3.1. RAVE-incorporated algorithm . . . . . . 8
3.4. Echo top . . . . . . . . . 8
3.4.1. Quality-based Echo Top (ETOP) product generation – Product2D: ETOP . . 8
3.5. Maximum . . . . . . . . . 10
3.5.1. Quality-based maximum of reflectivity (MAX) product generation
– Product2D: MAX . . . . . . . . 10
3.6. Vertically integrated liquid water . . . . . . . 13
3.6.1. Quality-based vertically integrated liquid water (VIL) product generation
– Product2D: VIL . . . . . . . . 13
3.7. Ground-related precipitation, QPE . . . . . . 16
3.7.1. Networked VPR correction . . . . . . . 16
3.7.2. Combination of radar-based ground precipitation rate and raingauge
network data – COMBINATION . . . . . . 18
3.7.3. Precipitation accumulation – ACRR . . . . . . 21
3.8. Wind speed . . . . . . . . . 24
3.8.1. Vertical profile . . . . . . . . 24
3.9. Hydrometeor classification . . . . . . . 26
3.9.1. BALTRAD Hydrometer Classifier BALTRAD-HMC . . . . 26
3.9.2. Separation of convective and stratiform precipitation – CONVECTION . . 31
4. Quality-related data processing . . . . . . . 37
4.1. Brief catalogue of quality algorithms for 3D reflectivity data volumes . . . 37
4.1.1. Removal of geometrically-shaped non-meteorological echoes and quality
characterization (as a part of RADVOL-QC package) – RADVOL-QC: SPIKE . . 37
4.1.2. Removal of non-meteorological echoes and quality characterization
– RADVOL-QC: NMET . . . . . . . 37
4.1.3. Removal of measurement noise and quality characterization
– RADVOL-QC: SPECK . . . . . . . 38
4.1.4. Quality characterization due to distance to radar related effects
– RADVOL-QC: BROAD . . . . . . . 38
4.1.5. Correction of partial and total beam blockage and quality characterization
including ground clutter – RADVOL-QC: BLOCK . . . . 39
4.1.6. Correction and quality characterization for attenuation in rain
– RADVOL-QC: ATT . . . . . . . . 40
4.1.7. Polarimetric rain attenuation correction : rainATTENcorrect . . . 40
4.2. Brief catalogue of quality algorithms for 3D Doppler data volumes . . . 42
4.2.1. Dealiasing radial winds . . . . . . . 42
4.3. Total quality characterization . . . . . . . 43
4.3.1. Total quality index (QI) for scans/volumes – QI_TOTAL . . . . 43
5. Data visualization . . . . . . . . . 45
6. Abbreviations . . . . . . . . . 46
7. References . . . . . . . . . 47
3
1. Motivation
The report has been prepared in the frame of BALTRAD+ Project as part of work carried out in Work
Package 4 “Pilot investment and real-world use”. Above all, it is based on product descriptions
contained in the Project “cookbook”, where "recipes" of algorithms are collected (see:
http://git.baltrad.eu/trac/wiki/cookbook).
Moreover, experience and information gathered in the frame of works on other project reports,
especially “Final version of catalogue of radar-based products which end-users are interested in”
(BALTRAD+ W4-31), were useful.
Other sources:
1. BALTRAD W701 report “Definition of the target end-users” (Szturc et al., 2009).
2. BALTRAD W702 report “The end-users requirements and expectations” (based on
questionnaire) (Szturc et al., 2010).
3. BALTRAD W703 report on Application Case Log (Szturc et al., 2012).
4. Presentations during the following BALTRAD events:
− End-User Workshop, 26 October 2010, Aalborg, Denmark,
− BALTRAD Final Seminar, 7 December 2011, Tallinn, Estonia,
− BALTRAD+ User Forum I, 16 May 2012, Kraków, Poland,
− BALTRAD+ User Forum II, 5 December 2012, Norrköping, Sweden,
− BALTRAD+ User Forum III, 16 May 2013, Vilnius, Lithuania,
− BALTRAD+ User Forum IV, 21-22 November 2013, Berlin, Germany.
5. Research papers.
2. BALTRAD+ products classification
In general, weather radar data can be divided into two groups:
1. Three-dimensional (3D) data written in spherical coordinates as set of two-dimensional
scans. They are often called “volumes” (data volumes) or “raw data”.
2. Two-dimensional (2D) Cartesian data as cross-section or more complicated information
written in 2D form, called “products”.
The 3D volumes are not highly useful for weather radar users because they are difficult to interpret.
For this reason numerous 2D products can be generated from volumes. There is set of a few tens of
standard products, but many products dedicated to specific users can be defined and generated. In
this report the 2D products developed in the frame of the BALTRAD+ project are described.
The products may include different meteorological quantities like the standard ones: radar
reflectivity (Z, in mm6 m
-3 or dBZ), precipitation rate (R, in mm h
-1), and wind speed (V, in m s
-1), or
their derivates, like Echo Top (ET, in m) or Vertically Integrated Liquid Water (VIL, in dBA or mm).
All the products generated by BALTRAD system may be quality controlled (post-processed), i.e.
corrected and quality characterized, by means of set of quality algorithm that are developed for the
system needs.
In Table 1 general classification of reflectivity-based radar products is presented whatever they are
available in BALTRAD system at present or not.
4
Table 1. Classification of BALTRAD system products.
Subsection
number
Basic
meteorological
quantity
Class of
product
ODIM
(standard)
denotations
BALTRAD
implementations
State of works
(end of 2013)
3.1.1 Radar reflectivity,
Z (in dBZ)
Plan position
indicator
PPI Product2D: PPI
(IMGW)
Completed
3.2.1 Radar reflectivity,
Z (in dBZ)
Constant
altitude PPI
CAPPI,
PCAPPI
RAVE Completed
3.3.1 Radar reflectivity,
Z (in dBZ)
Range height
indicator
RHI, XSEC RAVE Completed
3.4.1 Height of echo
top, h (in km)
Echo top ETOP Product2D: ETOP
(IMGW)
Completed
3.5.1 Radar reflectivity,
Z (in dBZ)
Maximum MAX Product2D: MAX
(IMGW)
Completed
3.6.1 Liquid water
content, VIL (in
mm)
Vertically
integrated
liquid water
VIL Product2D: VIL
(IMGW)
Completed
3.7.1 Precipitation rate,
R (in mm h-1
)
Ground-related
precipitation,
QPE
-- Networked VPR (FMI) Completed
3.7.2 Precipitation rate,
R (in mm h-1
)
Ground-related
precipitation,
QPE
-- COMBINATION
(IMGW)
Research
ongoing
3.7.3 Precipitation
accumulation, R
(in mm h-1
)
Ground-related
precipitation,
QPE
ACRR (SMHI, FMI) Completed
3.8.1 Wind speed, V (in
m s-1
)
Vertical profile VP WRWP (SMHI) Completed
3.9.1 Classes of echoes Hydrometeor
classification
CLASS BALTRAD-HMC (DMI) Completed
3.9.2 Classes of echoes Convection
detection
CLASS CONVECTION (IMGW) Research
ongoing
3. Catalogue of 2D products
3.1. Plan Position Indicator
3.1.1. Quality-based PPI (Plan Position Indicator) product generation – Product2D: PPI
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
Basic description
Physical basis of the algorithm
5
The algorithm interpolates polar data into Cartesian coordinates employing quality
information (quality index e.g. from QI_TOTAL processing). It can be applied e.g. to
radar reflectivity Z after VPR-based extrapolation down to ground.
The product is the basis for generating other 2-D products.
Amount of validation performed so far
Not performed yet.
References (names and contact information of all developers during the evolutionary history,
scientific papers)
IMGW, Department of Ground Based Remote Sensing.
ODIM metadata requirements for I/O
Input data: SCAN
� General “what”: source(NOD).
� Dataset-specific “where” for data and QI: nbins, nrays.
� Data-specific “what” for data: gain, offset, nodata, undetect.
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Output data: Cartesian data
� Top-level “where”: lon, lat, xsize, ysize, xscale, yscale.
� Dataset-specific “what”: product.
� Data-specific “what” for data: gain, offset, nodata, undetect.
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
� Radar-based quantity, e.g. reflectivity data after corrections DBZH as SCAN object.
� Optionally QI information QIND (generated e.g. by QI_TOTAL algorithm) included in the
same SCAN object.
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
� Defined projection and domain of Cartesian output.
Logical steps, using any of: text, flow charts, graphics, equations (or references to equations),
conditional branches in “all possible cases”.
The algorithm transforms values for measurement gates of polar coordinates (α, l), where α
is the azimuth, l is the distance from the radar site, into values interpolated for Cartesian
pixels defined by coordinates: (x, y).
Fig. 1. Scheme of interpolation of gate values into Cartesian pixel.
Algorithm parameters
Set of the algorithm parameters:
Description Denotation Available options Default value
Interpolation method Method nearest / uniform / inverse1 bilinear
6
/ inverse2 / bilinear /
cressman
Input quantity identifier Quantity TH / DBZH / ... DBZH
If to employ quality
information QI for
interpolation
IncludeQuality 0 (no) / 1 (yes) 1
Input quality field name QIField pl.imgw.qi_total /
se.smhi.detector.poo / ...
pl.imgw.qi_total
If to interpolate values in
mm6 m
-3 (for Quantity =
TH / TV / DBZH / DBZV /
ZDR)
dBZtoZ 0 (no) / 1 (yes) 1
Separation of pixels due to distance to radar
The algorithm interpolates data in different ways for pixels close to radar site, where
there is dense pattern of gates, and farther from radar site (so called inside and
outside method). The border in distance to radar (D) is defined by empirically
determined function of measurement parameters: step in azimuth dAz (°), step in
distance from radar dbin (km), and Cartesian spatial resolution dx (km):
For instance, for dAz = 1°, dbin = 1 km, and dx = 1 km the D = 57,5 km.
Inside method
For the centre of Cartesian pixel its four corners are considered, which coordinates
are transformed into polar coordinates defining investigation area in polar data. Then
the number of gates inside this area is determined. If it is higher than 2 the inside
method based on quality weighted interpolation is employed:
where n is the number of gates inside the investigation area.
Otherwise (if the number of gates inside the investigation area is not higher than 2)
the outside method is applied.
Outside method
In outside method the closest gates are determined in the following way. The
coordinates of the Cartesian pixel centre are transformed into polar coordinates and
four surrounding gates are taken into account. In case when difference between the
considered pixel centre and one or two the investigated gates is lower than the
preset limit (5% of "rscale" or azimuth step in terms of distance to radar or azimuth
respectively) then only the closest gates are taken into calculations.
Then quantity in given pixel of coordinates (x, y) is estimated as weighing average
value Z(x, y) from the n selected gates Zi, taking both distances to the gates and data
quality information in the gates into account:
where: WDi is the weight related to distance of i-gate to pixel (x, y); WQIi is the quality
index QI of the i-gate; n is the number of the closest gates taken into account.
Determination of weigths in outside method
The polar coordinates of selected i-gate are transformed into Cartesian coordinates
(xi, yi) in order to determine its distance to the considered pixel (x, y):
Weights due to distances to gates Di are determined by means of the following
methods:
� nearest:
7
� uniform:
� inverse1:
� inverse2:
� bilinear:
where Ai is the area of annulus sector.
Fig. 2. Scheme of bilinerar interpolation.
� cressman:
where a is the influence radius, a = 10 km; if Di > a then WDi = 0. If for the
considered pixel there are no gates with Di < a then the calculation is repeated
with longer a = 20 km.
Weights due to data quality for 1, .., n pixels are determined as:
Data quality characterization
Quality index for interpolated pixel (x, y) is calculated in dependence on method
applied to data interpolation:
� for inside method
� for outside method
where: WDi are the distance-related weights for n selected gates.
Output
Data type using ODIM notation where possible, e.g. DBZH
Input quantity as IMAGE or COMP objects (in Cartesian coordinates) with:
� "pl.imgw.product2d.ppi" in quality-specific "how": task,
� interpolation method, selected quality field name, and whether values were
interpolated in mm6 m
-3, listed in "how": task_args.
Quality index (QI) field
Quality index field QIND as IMAGE or COMP objects with:
� "pl.imgw.product2d.ppi" in quality-specific "how": task,
� interpolation method and selected quality field name listed in "how": task_args.
References
-
8
3.2. Constant altitude PPI
3.2.1. RAVE-incorporated algorithm (3PMAX composite generation)
The algorithm is under development.
3.3. Range height indicator
3.3.1. RAVE-incorporated algorithm
The algorithm is under development.
3.4. Echo top
3.4.1. Quality-based Echo Top (ETOP) product generation – Product2D: ETOP
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
Basic description
Physical basis of the algorithm
The algorithm generates Echo Top (ETOP) 2-D product from radar reflectivity volume
with quality information using product2D_PPI algorithm.
Amount of validation performed so far
Not performed yet.
References (names and contact information of all developers during the evolutionary history,
scientific papers)
IMGW, Department of Ground Based Remote Sensing.
ODIM metadata requirements for I/O
Input data: VOL
� General “what”: source(NOD).
� For particular SCANs:
� Dataset-specific “where” for data and QI: nbins, nrays.
� Data-specific “what” for data: gain, offset, nodata, undetect.
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Output data: Cartesian data
� Top-level “where”: lon, lat, xsize, ysize, xscale, yscale.
� Dataset-specific “what”: product.
� Data-specific “what” for data: gain, offset, nodata, undetect.
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
� object=PVOL:
� quantity=DBZH, otherwise TH,
� quantity=QIND (generated e.g. by QI_TOTAL algorithm).
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
� Defined projection and domain of Cartesian output.
9
Logical steps, using any of: text, flow charts, graphics, equations (or references to equations),
conditional branches in “all possible cases”.
The algorithm generates Echo Top (ETOP) 2-D products in Cartesian coordinates from radar
reflectivity volume and based on the data quality information.
Algorithm parameters
Set of the algorithm parameters:
Description Denotation Unit Default value
Lower height limit for ETOP product generation ETOP_hMin km 4
Upper height limit for ETOP product generation ETOP_hMax km 20
Minimum cloud reflectivity ETOP_ZMin dBZ 4
Algorithm description
Echo Top (ETOP) product represents Cartesian image of height of echo (cloud) tops
defining cloud boundary with proper level of radar reflectivity Z0 (in dBZ) (Fig. 1). The
ETOP (in km) is detected in a preset range of height (between hmin and hmax) and
generally is calculated by interpolation of reflectivity Z between two highest gates for
which the reflectivity passes Z0 value. If searched height of Z0 value is between two
measurements Z’ and Z” detected at heights h’ and h” respectively, then in order to
find the height hint at which echo top occurs (Z = Z0) the linear interpolation is
applied:
In case when both considered measurements are with echo (Z ≥ Z0) then hint = min
(hmax, max (h’, h”)).
Fig. 1. Scheme of generation of radar Echo Top product (ETOP).
There are considered only measurements (Cartesian pixels on PPIs) between hmin and
hmax, and two closest ones (below hmin and above hmax). At first, height h of the
highest measurement with echo (Z ≥ Z0) is found.
The following cases may occur:
� h > hmax and lower measurement exists, then echo top hint is interpolated from
the two measurements, and:
− if hint > hmax then ETOP = “undetect” and lower echo (Z ≥ Z0) is analyzed if
exists,
− if hint <= hmax then ETOP = hmax.
� h > hmax and lower measurement does not exist, then ETOP = “nodata”.
� h <= hmax and higher measurement exists, then echo top hint is interpolated
from the two measurements, and:
− if hint ≥ hmin then ETOP = min (hint, hmax),
10
− if hint < hmin then ETOP = “undetect”.
� h <= hmax and higher measurement does not exist, then:
− if h ≥ hmin then ETOP = h,
− if h < hmin then ETOP = “nodata”.
Otherwise, i.e. echo (Z ≥ Z0) is not found, then:
� if there so no measurement between hmin and hmax then ETOP = “nodata”,
� else ETOP = “undetect”.
Data quality characterization
Quality of the ETOP depends on the two factors:
� quality of reflectivity data from which ETOP was determined, QIsource,
� how large fraction of investigated heights (between hmin and hmax) was
scanned, QIscope,
and the final quality index QI is taken as a product of the both factors:
The value of the first component QIsource is taken as the quality of the measurement
defining echo top, and in case of interpolation from two measurements the minimum
quality is chosen. If ETOP = “nodata” then QIsource = “nodata”, and if ETOP =
“undetect” then QIsource = 1.
Fig. 2. Quality characterization for Echo Top product in terms of availability.
The second component QIscope is determined based on heights of the highest and
lowest scans for considered Cartesian pixel (hhighest and hlowest respectively) in relation
to hmin and hmax (Fig. 2):
� if hhighest < hmin then
QIscope = “nodata” and QI = “nodata”.
� if hhighest ≥ hmin and hlowest <= hmax then QIscope depends on what part of height
range between hmin and hmax was scanned:
but if (hhighest > hmax) and (ETOP <> “undetect”) then QIscope = 1.
� if hlowest > hmax then
QIscope = “nodata” and QI = “nodata”.
Output
Data type using ODIM notation where possible, e.g. DBZH
Input quantity as IMAGE object (in Cartesian coordinates) with:
� "how": task - "pl.imgw.product2d.etop",
� "how": task_args
� parameters inherited from PPI algorithm (interpolation method and selected
quality field name),
11
� parameters of ETOP algorithm,
Quality index (QI) field
Quality index field QIND as IMAGE object with:
� "how": task - "pl.imgw.product2d.etop",
� "how": task_args - parameters inherited from PPI algorithm (interpolation
method and selected quality field name).
References
-
3.5. Maximum
3.5.1. Quality-based maximum of reflectivity (MAX) product generation – Product2D: MAX
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
Basic description
Physical basis of the algorithm
The algorithm generates maximum of reflectivity (MAX) 2-D product from radar
reflectivity volume with quality information using product2D_PPI algorithm.
Amount of validation performed so far
Not performed yet.
References (names and contact information of all developers during the evolutionary history,
scientific papers)
IMGW, Department of Ground Based Remote Sensing.
ODIM metadata requirements for I/O
Input data: VOL
� General “what”: source(NOD).
� For particular SCANs:
� Dataset-specific “where” for data and QI: nbins, nrays.
� Data-specific “what” for data: gain, offset, nodata, undetect.
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Output data: Cartesian data
� Top-level “where”: lon, lat, xsize, ysize, xscale, yscale.
� Dataset-specific “what”: product.
� Data-specific “what” for data: gain, offset, nodata, undetect.
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
� object=PVOL:
� quantity=DBZH, otherwise TH,
� quantity=QIND (generated e.g. by QI_TOTAL algorithm).
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
Defined projection and domain of Cartesian output.
Logical steps, using any of: text, flow charts, graphics, equations (or references to equations),
conditional branches in “all possible cases”.
12
The algorithm generates maximum of reflectivity (MAX) 2-D products in Cartesian
coordinates from radar reflectivity volume and based on the data quality information.
Algorithm parameters
Set of the algorithm parameters:
Description Denotation Unit Default value
Lower height limit for MAX product generation MAX_hMin km 1
Upper height limit for MAX product generation MAX_hMax km 20
Algorithm description
Maximum of reflectivity (MAX) product represents Cartesian image of highest
measured value of radar reflectivity Z (in dBZ) for each vertical column. The
maximum is detected in a preset range of height (between hmin and hmax) and
generally is a search for the highest value among reflectivities in pixels in the column
for all PPIs (Fig. 1).
Fig. 1. Scheme of generation of maximum of radar reflectivity product (MAX).
Data quality characterization
Quality of the MAX depends on the two factors:
� quality of reflectivity data taken as MAX, QIsource,
� how large fraction of investigated heights (between hmin and hmax) was scanned,
QIscope,
and the final quality index QI is taken as a product of the both factors:
The value of the first component QIsource is taken as the quality of the measurement
defining MAX. If MAX = “nodata” then QIsource = “nodata”, and if MAX = “undetect”
then QIsource = 1.
Fig. 2. Quality characterization for maximum of reflectivity product in terms of availability.
13
The second component QIscope is determined based on heights of the highest and
lowest scans for considered Cartesian pixel (hhighest and hlowest respectively) in relation
to hmin and hmax (Fig. 2):
� if hhighest < hmin then
QIscope = “nodata” and QI = “nodata”.
� if hhighest ≥ hmin and hlowest <= hmax then QIscope depends on what part of height
range between hmin and hmax was scanned:
� if hlowest > hmax then
QIscope = “nodata” and QI = “nodata”.
Output
Data type using ODIM notation where possible, e.g. DBZH
Input quantity as IMAGE object (in Cartesian coordinates) with:
� "how": task - "pl.imgw.product2d.max",
� "how": task_args
� parameters inherited from PPI algorithm (interpolation method and selected
quality field name),
� parameters of MAX algorithm,
Quality index (QI) field
Quality index field QIND as IMAGE object with:
� "how": task - "pl.imgw.product2d.max",
� "how": task_args - parameters inherited from PPI algorithm (interpolation
method and selected quality field name).
References
-
3.6. Vertically integrated liquid water
3.6.1. Quality-based vertically integrated liquid water (VIL) product generation – Product2D: VIL
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
Basic description
Physical basis of the algorithm
The algorithm generates vertically integrated liquid water (VIL) 2-D product from
radar reflectivity volume with quality information using product2D_PPI algorithm.
Amount of validation performed so far
Not performed yet.
References (names and contact information)
IMGW, Department of Ground Based Remote Sensing.
ODIM metadata requirements for I/O
Input data: VOL
� General “what”: source(NOD).
� For particular SCANs:
� Dataset-specific “where” for data and QI: nbins, nrays.
� Data-specific “what” for data: gain, offset, nodata, undetect.
14
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Output data: Cartesian data
� Top-level “where”: lon, lat, xsize, ysize, xscale, yscale.
� Dataset-specific “what”: product.
� Data-specific “what” for data: gain, offset, nodata, undetect.
� Data-specific “what” for QI: gain, offset, nodata, undetect.
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
� object=PVOL:
� quantity=DBZH, otherwise TH,
� quantity=QIND (generated e.g. by QI_TOTAL algorithm).
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
� Defined projection and domain of Cartesian output.
Logical steps
The algorithm generates vertically integrated liquid water (VIL) 2-D products in Cartesian
coordinates from radar reflectivity volume and based on the data quality information.
Algorithm parameters
Set of the algorithm parameters:
Description Denotation Unit Default value
Lower height limit for VIL product generation (a.s.l.) VIL_hMin km 2
Upper height limit for VIL product generation (a.s.l.) VIL_hMax km 10
Coefficient c in Z-M formula VIL_ZMc - 24000
Coefficient d in Z-M formula VIL_ZMd - 1.82
Algorithm description
Vertically integrated liquid water (VIL) product represents Cartesian image of the
water content residing in a user-defined layer in the atmosphere (in dBA) (Fig. 1).
Generally, in the first step a vertical profile of liquid water content M (based on Z-M
relationship) is determined by interpolation between all pairs of neighbouring
measurements. Then the VIL in a preset range of height (between hmin and hmax) is
calculated by integration of the profile. In order to find the vertical profile of M(h),
values between two measurements M’ and M” detected at heights h’ and h”
respectively, the linear interpolation is applied:
Fig. 1. Scheme of generation of vertically integrated liquid water product (VIL).
Radar reflectivity Z is related to liquid water content M (in cm3 m
-3) according to so
called Z-M relationship:
15
where constants: c = 24 000; d = 1.82 (as proposed by Selex, 2010).
The VIL (vertically integrated liquid water content) is defined as:
In the VIL algorithm there are considered only measurements (Cartesian pixels on
PPIs) between hmin and hmax, and two closest ones (below hmin and above hmax).
The following ranges of integration are considered:
� If the highest measurement is higher than hmax, then the two measurements
above and below hmax are interpolated and values of M below hmax are taken
for integration, else the integration is performed up to height of the highest
measurement.
� If the lowest measurement is lower than hmin, then the two measurements
above and below hmin are interpolated and values of M above hmin are taken
for integration, else the integration is performed with the assumption that the
lowest measurement was also at hmin.
Data quality characterization
Quality of the VIL depends on the two factors:
� quality of reflectivity data from which VIL was determined, QIsource,
� how large fraction of investigated heights (between hmin and hmax) was
scanned, QIscope,
and the final quality index QI is taken as a product of the both factors:
The value of the first component QIsource is taken as an average quality of all
measurements defining VIL. If VIL = “nodata” (there is no measurement between hmin
and hmax) then QIsource = “nodata”, and if VIL = “undetect” (there is no detected
reflectivity between hmin and hmax) then QIsource = 1.
Fig. 2. Quality characterization for vertically integrated liquid water product in terms of scope.
The second component QIscope is determined based on heights of the lowest and
highest scans for considered Cartesian pixel (hlowest and hhighest respectively) in relation
to hmin and hmax (Fig. 2):
� if hhighest < hmin then
QIscope = “nodata” and QI = “nodata”.
� if hhighest ≥ hmin and hlowest <= hmax then QIscope depends on what part of height
range between hmin and hmax was scanned:
� if hlowest > hmax then
QIscope = “nodata” and QI = “nodata”.
16
Output
Data type using ODIM notation where possible, e.g. DBZH
Input quantity as IMAGE object (in Cartesian coordinates) with:
� "how": task - "pl.imgw.product2d.vil",
� "how": task_args
� parameters inherited from PPI algorithm (interpolation method and selected
quality field name),
� parameters of VIL algorithm,
Quality index (QI) field
Quality index field QIND as IMAGE object with:
� "how": task - "pl.imgw.product2d.vil",
� "how": task_args - parameters inherited from PPI algorithm (interpolation
method and selected quality field name).
References
-
3.7. Ground-related precipitation, QPE
3.7.1. Networked VPR correction
Authors
Joonas Karjalainen, Jarmo Koistinen
Finnish Meteorological Institute
ODIM metadata requirements for I/O
/dataset/what: gain, offset, nodata
Input data
Full volume scan reflectivity data(for each radar). At FMI the VPR correction for a 500 m
PseudoCAPPI composite is performed presently applying the 4 lowest elevation angles from
each radar. Other number of elevations can be applied according to the user selections.
Other data:
The classification scheme of VPRs embedded into the correction algorithm and used in real
time requires that the height of the freezing level is known at each radar site at each volume
scan moment. At FMI that is estimated from NWP nowcasting data applying the HIRLAM
model fields of temperature.
Short description
The vertical profile of radar reflectivity factor (VPR) and the measurement geometry of
weather radar introduce a vertical sampling difference between the actual precipitation at
ground level and the radar estimate of it. VPR correction is used to modify the measured
values so that they represent the precipitation conditions at ground level more accurately.
The networked VPR correction described here denotes that the correction is calculated in
radar networks so that the adjustment factor field will be continuous, not introducing
additional steps at the seam lines where measured data from neighboring radars meet.
18
3.7.2. Combination of radar-based ground precipitation rate and raingauge network data –
COMBINATION
Authors
Anna Jurczyk, Jan Szturc, Katarzyna Ośródka
Institute of Meteorology and Water Management – National Research Institute
Basic description
19
Final precipitation estimate is generated as combination of corrected radar-based
precipitation rate with data from raingauge. Three options/techniques are available:
− simple mean field bias (MFB),
− local-oriented MFB,
− conditional merging of the two kinds of precipitation information.
Amount of validation performed so far
Prototype was developed and tested in the frame of RISK-AWARE Project (2003-
2007).
References
IMGW, Department of Ground Based Remote Sensing.
ODIM metadata requirements for I/O
− Top-level “what”: object, data, time.
− Top-level “where”: lon, lat, projdef, xsize, ysize, xscale, yscale, LL_lon, LL_lat, UL_lon,
UL_lat, UR_lon, UR_lat, LR_lon, LR_lat.
− Dataset-specific “what”: product, gain, offset, nodata, undetect.
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
One of weather radar products that reflects ground precipitation rate RATE or
accumulation ACRR as IMAGE or COMP files: PPI, CAPPI, PCAPPI, MAX, etc.
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
Data from raingauge telemetric network.
Logical steps
Radar data is considered to be better then raingauge network in reproduction of spatial
distribution, whereas raingauges measure precipitation accurately in their locations. This
observation was a starting point of conditional merging (Sinclair and Pegram 2005). In this
approach the information from radar is used to obtain the correct spatial structure of the
precipitation field, while the field values are fitted to the raingauge observations. The
method consists of the following steps:
1. Spatial interpolation of raingauge-derived precipitation data is performed using one
of known methods (here IDW or ordinary Kriging). Resulting field is denoted as RG.
2. Next deviations between observed and interpolated radar values are calculted (RR) in
the following way:
− spatial interpolation of radar data only from pixels with raingauge locations (field
RR’),
− calculation of differences between the two maps (RR – RR’),
3. Finally spatially interpolated raingauge data is corrected using the differences (errors
of interpolation) according to the following formula:
where R’ is the merged precipitation estimate.
Gauge and radar spatial interpolation should be performed by the means of the same
method.
Two simplified techniques are available as well: simple mean field bias (MFB) and local-
oriented MFB.
Quality of merging method was evaluated applying data from May to September 2006. The
two methods of spatial interpolation, IDW and ordinary Kriging, implemented in combination
were tested. Radar data as 1-hour accumulations were employed. Raingauge set was divided
into two subsets: 1-hour accumulation data from the first one were used in combination and
from the second one for verification (10% of the whole number). Characteristics obtained
20
using IDW method are slightly better than using Kriging (e.g., RMSE equals 0.56 for IDW
whereas 0.61 for Kriging, and correlation coefficient equals 0.70 and 0.68, respectively).
Example of the algorithm running: a) radar field, b) spatially interpolated raingauge measurements, c)
spatially interpolated radar measurements from raingauge locations, d) merged field.
In Figure above an example of the conditional merging algorithm performance is shown. It
illustrates one of effects of using the technique: the combined field maintains the spatial
pattern of the radar field. Correlation coefficient between the combined field and radar one
equals 0.86 whereas between the combined field and interpolated raingauges (using IDW
method) only 0.59. On the other hand final combined rainfall field follows the mean field of
raingauge interpolation. For the whole period May–September 2006 the mean values are
0.130 mm for combined field and 0.126 mm for raingauges against 0.157 mm for radar. The
results are obtained for point data (in raingauge locations) using IDW method in
combination.
Output
− Field of adjusted precipitation rate RATE or accumulation ACRR as IMAGE or COMP
object.
− Quality index field QIND as IMAGE or COMP object.
References
− Jurczyk, A., Ośródka, K., and Szturc, J., 2008. Research studies on improvement in real-
time estimation of radar-based precipitation in Poland. Meteorol. Atmos. Phys., 101, 159-
173.
− Sinclair, S. and Pegram, G., 2005. Combining radar and rain gauge rainfall estimates using
conditional merging. Atmos. Sci. Lett., 6, 19-22.
21
3.7.3. Precipitation accumulation - ACRR
Authors
Daniel Michelson
Swedish Meteorological and Hydrological Institute
Harri Hohti
Finnish Meteorological Institute
Basic description
Physical basis of the algorithm
Derive an accumulated precipitation product based on a set of input reflectivity
products, either single-site or, more likely, composite.
Amount of validation performed so far
Prototype developed and tested for OPERA.
References (names and contact information of all developers during the evolutionary history,
scientific papers)
Sort-of based on the method used at the BALTEX Radar Data Center, but in new form.
ODIM metadata requirements for I/O
Input
� gain, offset, nodata, and undetect for reflectivity datasets
� how/task = se.smhi.composite.distance.radar for surface distance quality indicator
fields
� gain and offset for the surface distance QI fields
Output
� Output physical parameter must have what/quantity=ACRR
� what/prodpar of the ACRR dataset must be set to the integration period (hours)
� Otherwise, metadata are the same as for input data, just that gain and offset will need
to be adjusted.
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
Reflectivity data are the most relevant: normally DBZH, but also TH. It's probably
unlikely that someone would want to accumulate TV or DBZV, but we might support
them too. We don't have much of a tradition of storing data as RATE (mm/h), so
these may be considered less relevant and not supported.
It is assumed here that the fixed R(Z) conversion of this algorithm is applied only until
the dynamic only conversion is available. If dynamic R(Z) conversion is applied then it
is recommended that the conversion and the accumulation are split in two separate
algorithms.
Data can be in any stage of quality. Optionally, a quality indicator dataset containing
surface distance from the radar, that accompanies a reflectivity field, can be used to
derive an average distance field that will accompany the output ACRR result.
Otherwise, it doesn't make sense to make the accumulator somehow average all the
various forms of quality indicators we may produce, at least not without careful
consideration that we won't deal with in this first version.
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
None
Logical steps, using any of: text, flow charts, graphics, equations (or references to equations),
conditional branches in “all possible cases”.
22
Required arguments
Information Type
Input data List of file names
Nominal date YYYYMMDD according to ODIM
Nominal time HHmmss according to ODIM
Nr. hours float
Images per hour integer
Proportion accepted float (0-1), e.g. 0.95 for 95%
A coefficient in Z-R float
b coefficient in Z-R float
Algorithm
It's a two-step process. Step 1 involves looping through all input images and
determining the sum of all the precipitation intensities in the time series. If the
surface distance QI field exists, also sum the distances.
A couple of notes on determining input data:
The total number of input files in the time series is (nr.hours)*(images per hour)+1.
For example, if we have an image every 15 min, there will be five images for a one-
hour accumulation.
The scheduler (Beast) will have to find input data based on the nominal date/time
which is always the end of the integration period.
It's important to use counters to keep track of how many hits in the time series there
are. This will be used in step 2 to accept or reject results. Step 1 can be illustrated
schematically as follows:
23
Step 2 takes the results of step 1 and loops one last time, using the counters to
derive ACRR results and, optionally, an associated mean distance QI field.
Schematically, this is:
24
Output
The result is an ODIM_H5 file containing a composite with an ACRR quantity and, optionally,
an associated average surface distance quality indicator field.
a) Data type using ODIM notation where possible, e.g. DBZH
� ACRR
b) Added quality indicators
� With how/task = se.smhi.composite.distance.radar
References
-
3.8. Wind speed
3.8.1. Vertical profile
Authors
Günther Haase
Swedish Meteorological and Hydrological Institute
Basic description
The algorithm is based on the VVP method.
25
ODIM metadata requirements for I/O
nbins, nrays, gain, offset, nodata, undetect, rscale, elangle
Input data
Polar volume or scan
Logical steps
This algorithm derives vertical profiles of reflectivity, wind speed, and wind direction from
polar volume data.
Assuming a uniform wind field the radial wind (V) has the form of a sine for constant range
and elevation angle:
where φ is the azimuth angle. The four constants are amplitude (|α|), period (2π/k), phase
shift (β), and vertical displacement (γ). The terminal velocity of the falling hydrometeors is
implicitly included in γ. For k=1 Eq. (1) yields
with
Equation (3) can be extended to n velocities which results in a nonhomogeneous matrix
equation of the form:
For more than three independent measurements, i.e. n>3, Eq. (7) is an overdetermined linear
system which can be solved using a QR factorization of A. The resulting values w1, w2, and w3
are utilized to determine α, β, and γ in Eq. (2). Squaring and adding Eqs (4) and (5) leads to
Solving Eq. (4) for α and inserting it into Eq. (5) results In
Finally, Eq. (6) provides an expression for the vertical displacement γ. Hence, Eq. (2) describes
the radial wind model which is closest to the observations. The real wind velocity is identical
with the amplitude α in Eq. (8) while the wind direction is obtained from the derivative with
respect to azimuth angle
Hence, Eq. (9) equals zero for
26
where φ1 and φ2 are the extreme values of Eq. (2). The second derivative of Eq. (2) with
respect to azimuth angle is
From Eq. (8) we know that α>0. Thus, the radial velocity in Eq. (2) has a maximum at φ1 and a
minimum at φ2. Usually the wind direction is expressed in terms of the direction from which
the wind originates (for example, a westerly wind blows from the west to the east).
Furthermore, radial velocities away from the radar (outbound) are defined as positive while
velocities towards the radar (inbound) are defined as negative. Therefore the wind direction
in the specified height layer is given by φ2.
Output
dbz, dbz_dev, ff, ff_dev, dd, n (DBZH/VRAD)
3.9. Hydrometeor classification
3.9.1. BALTRAD Hydrometer Classifier BALTRAD-HMC
Authors
Rashpal S. Gill and Martin B. Sørensen
Danish Meteorological Institute
Basic description
Pixel based hydrometeor classification is carried out using the fuzzy logic methodology (Bringi
and Chandrasekar, 2001, Zrnic et. al., 2001, Schuur et. al., 2003, Lim et. al., 2005). In the
current approach, a given pixel of hydrometeor class j has a score Sj given by the relation
where Pi and Wi are the value of the parameter i, and the associated weight, for the class j.
The radar parameters that have been used in the classifier are: ZHH, ZDR, KDP, σHV , plus the
texture parameters, associated with ZHH, ZDR, ФDP (Schuur et. al., 2003, Sugier et. al., 2006). In
fuzzy logic the values of the Pi for the different hydrometeor classes are described by the
membership functions (MF) (see section 4).
Hydrometeor classes
In the current version of the algorithm the following 12 hydrometeor classes have been
identified:
1. ground clutter,
2. sea clutter,
3. electrical signals from external emitters (EE) that interfere with our radars,
4. clean air echoes (CAE) such as from birds and insects,
5. drizzle,
27
6. light rain,
7. moderate rain,
8. heavy rain,
9. violent rain,
10. light snow,
11. moderate to heavy snow,
12. rain/hail mixture.
However, internally in the BALTRAD-HMC software there are two classes each of ground and
sea clutter, ten classes of external emitters including the signals from the sun and three
classes of CAE. Further, the light rain class consists of four sub-classes; light drizzle, moderate
drizzle, heavy drizzle and light rain.
Computational procedure
The software consists of two main modules:
1. Computation of all the radar parameters that are to be used in the fuzzy logic
classifier
2. Using fuzzy logic rules classify each pixel of the radar returned echo into one of the
predefined hydrometeor classes.
The computational procedure involves the following steps for module A:
1. from the radar volume file read in the following radar parameters: reflectivity ZHH,
differential reflectivity ZDR, cross correlation σHV, differential phase ФDP, radial velocity
Vr and spectral width W
2. by changing the default settings in the metadata file, choose whether to undertake
the following operations:
� smooth ZDR and σHV parameters, by averaging over N number of range gates,
� correct ZDR and σHV at low signal-to-noise (SNR) ratio values,
� correct ZDR and ФDP for radome effects,
� correct ZDR and ФDP for potential biases,
� compute the specific differential phase, KDP, as described in section 4 above,
� correct both ZHH and ZDR for rain attenuation as described in section 5 above.
3. now compute the following radar parameters in their appropriate units:
4. ZHH (unit dBZ) and its texture parameter, Tex(ZHH),
5. ZDR (unit dB) and its texture parameter, Tex( ZDR),
6. σHV and its texture parameter, Tex(σHV),
7. ФDP (unit deg.) and its texture parameter, Tex(ФDP),
8. KDP (unit deg./km) and its texture parameter, Tex(KDP),
9. Vr (unit m/s) and its texture parameter, Tex(Vr),
10. W (unit m/s) and its texture parameter, Tex(W),
11. signal-to-noise ratio parameter, SNR (unit dB), and
12. the top, centre and bottom heights (unit meters) of the radar beam, HTT, HTC and
HTB, respectively.
The computational procedure involves the following steps for module B:
1. read in all the computed radar parameters from module A
2. by changing the default settings in the metadata file, choose which of the above
parameters are to be used for level-1 and level-2 hydrometeor classification
3. read-in a , ß and γ indicating the centre, half- width at inflection point and the slope
of the curve of the Beta functions (see fig. 1), for each radar parameter including the
associated weights
4. for level-1 hydrometeor classification, for each radar echo
5. get the “scores “ of each of the parameter
6. using fuzzy logic rules compute the final score for each predefined classes
(precipitation, clutter, clean air echoes, and external emitters)
28
7. classify the pixel by choosing the predefined hydrometeor class with the highest
score
8. for level-2 hydrometeor classification
9. compute the heights of the melting layers using:
10. the radar volume data, and
11. from Numerical Weather Prediction (NWP) models
12. get the “scores “ of each of the parameter
13. using fuzzy logic rules compute the final score for each predefined classes (see
section 2)
14. classify the pixel by choosing the predefined hydrometeor class with the highest
score
Theoretical background
In fuzzy logic the values of the Pi, in equation (2), for the different hydrometeor classes are
described by the membership functions. In the current version the latter are expressed as
Beta functions of the type shown in fig. 1 with the 3 parameters: a, ß and γ indicating the
centre, half width at inflection point and the slope of the curve (Lim et. al., 2005).
Fig. 1 Beta membership function
As a way of example, fig. 2 shows the membership functions for the parameter ZHH for the
different classes of rain.
Fig. 2 Membership functions for ZHH for different categories of rain.
Similar membership functions exits for other hydrometeor classes for ZHH and for all the
other parameters used in the classification.
There has been much interest from international colleagues in the radar echo class 3
mentioned in section 2 above, because as far it is know, no hydrometeor classifier has
29
included a class for the external emitters before (Gill et. al., 2012). For this reason the
membership functions of ZHH ZDR and σHV for the different types of external emitters included
in the classifier are given below (fig. 3). Also note radar echoes from the sun are also a sub-
class of external emitters. Membership function of the sun plus those of external emitters for
the parameter ZHH can be seen in the bottom left part of fig. 3.
Fig. 3 Membership functions of ZHH, ZDR and rhoHV for the different types of external emitters included
in the classifier. Top left MF of a single external emitter of ZDR. Top right MF of all 9 external emitters
of ZDR . Bottom left of all 9 external emitters and of sun of ZHH. Bottom right MF of all 9 external
emitters of σHV
Examples of output from the hydrometeor classifier
The current version of the algorithm does the so-called level 1 and level 2 classifications. In
the level 1 classification a radar echo is classified into one of four simple classes:
precipitation, clutter, clean air echoes, and external emitters. Figure 4 shows an example of
the output.
Fig. 4 shows radar image on the left (ZHH original) and its corresponding level 1 hydrometeor
classification into four classes: external emitters (EE), clean air echoes (CAE), clutter and precipitation
(prec), colour code: yellow, blue, purple and green, respectively.
In the level 2 classification, the echoes that are classified as precipitation in level 1 are further
subclassified into different precipitation classes mentioned above. In this case the heights of
30
the melting layer computed by the local NWP model and/or estimated from the radar
parameters (see section 3) are used to strengthen the classification between the different
classes of rain and snow. In the current version of the level-2 classification only the
parameters ZHH, ZDR, KDP, and σHV are used. In particular, in this case score Sj is given by the
relation
Fig. 5 shows an example of the level 2 classification. Note that the radar data used to
illustrate the classifications results are the same in figures 4 and 5.
Fig. 5 shows radar image on the left (original ZHH) and its corresponding level 2 hydrometeor
classifications into eleven classes.
In addition to the above level 1 and 2 classifications, the algorithm can make use of the
above classification output to remove the non- meteorological echoes in the original radar
reflectivity product, ZHH, shown on the left in each of the figures 4 and 5. This is illustrated in
figure 6 below. Concerning the latter product, it was the first product that was requested for
routine operational use by the DMI end users, namely its meteorologists.
Fig. 6 shows the original radar product on the left and corresponding “cleaned” version on the right
which has non-meteorological echoes removed.
References
� Bringi, V.N., Chandrasekar, V., 2001. Polarimetric Doppler Weather Radar, Cambridge
Univ. Press, Cambridge, UK.
� Gill, R.S., Sørensen, M.B., Bøvith, T., Koistinen, J., Peura, M., Michelson, D., and Cremonini,
R., 2012. BALTRAD dual polarization hydrometeor classifier, ERAD 2012, 7th European
Conference on Radar in Meteorology and Hydrology.
31
� Lim, S., Chandrasekar, V., and Bringi, V.N., 2005. Hydrometeor classification system using
dualpolarization radar measurements: Model improvements and in situ verification, IEEE
Transactions of Geosciences and Remote Sensing, 43, 792-801.
� Schuur, T., Ryzhkov, A., and Heinselmann, P., 2003. Observations and classification of
echoes with the polarimetric WSR-88D radar, NOAA National Severe Storms Laboratory
Tech. Report, Norman, Oklahoma, USA.
� Sugier, J., Tabary, P., and Gourley, J., 2006. Evaluation of dual polarization technology at C
band for operational weather radar network, report of the EUMETNET OPERA II, work
packages 1.4 and 1.5.
� Zrnic, D.S., Ryzhkov, A., Straka, J., Liu Y., and Vivekanandan, J., 2001. Testing a procedure
for automatic classification of hydrometeor types, J. Atmos. Oceanic Tech, 18, 892-913.
3.9.2. Separation of convective and stratiform precipitation – CONVECTION
Authors
Anna Jurczyk, Jan Szturc, Katarzyna Ośródka
Institute of Meteorology and Water Management – National Research Institute
Basic description
Physical basis of the algorithm
The algorithm categorizes each radar pixel into convective or stratiform one
employing fuzzy logic approach with multi-source meteorological input data.
Amount of validation performed so far
Prototype was developed and tested in the frame of grant awarded by Polish
Ministry of Science and Higher Education (2009-2012)
References (names and contact information of all developers during the evolutionary history,
scientific papers)
IMGW, Department of Ground Based Remote Sensing.
ODIM metadata requirements for I/O
Input data
If input data: object=PVOL
• General “what”: source(NOD).
• For particular SCANs:
o Dataset-specific “where” for data and QI: nbins, nrays.
o Data-specific “what” for data: gain, offset, nodata, undetect.
o Data-specific “what” for QI: gain, offset, nodata, undetect.
If input data: object=IMAGE
• Top-level “what”: object, data, time.
• “Where”: lon, lat, projdef, xsize, ysize, xscale, yscale, LL_lon, LL_lat, UL_lon,
UL_lat, UR_lon, UR_lat, LR_lon, LR_lat.
• Dataset-specific “what” for data: product.
• Data-specific “what” for data: gain, offset, nodata, undetect.
• Data-specific “what” for QI: gain, offset, nodata, undetect.
Output data: Cartesian data
• Top-level “what”: object, data, time.
• “Where”: lon, lat, projdef, xsize, ysize, xscale, yscale, LL_lon, LL_lat, UL_lon,
UL_lat, UR_lon, UR_lat, LR_lon, LR_lat.
• Dataset-specific “what” for data: product.
• Data-specific “what” for data: gain, offset, nodata, undetect.
• Data-specific “what” for QI: gain, offset, nodata, undetect.
32
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
• object=PVOL (quantity=DBZH/TH) or three object=IMAGE: product=MAX
(quantity=DBZH), VIL (quantity=VIL), ETOP (quantity=HGHT).
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
• Meteosat products: Cloud Type; Overshooting Tops.
• Lightning detection data: Number of cloud-to-ground lightning.
• NWP model data: Convective Available Potential Energy (CAPE); Total Totals
Index (TTI).
Logical steps
The algorithm for separation of convective and non-convective precipitation is based on
multi-source meteorological data.
Algorithm parameters
Table 1. Set of the algorithm parameters (for standard version)
Description Denotation Default
value
Preliminary threshold for convection (dBZ) ThresholdConv 25
Lower threshold for convection area (km2) ThresholdAreaConv 4
Weight for member function of MAX for C class in fuzzy logic
scheme
MaxPar_weightC 0.3
Weight for member function of MAX for S class in fuzzy logic
scheme
MaxPar_weightS 0.3
Weight for member function of MAXDiff for C class in fuzzy logic
scheme
MaxDiff_weightC 0.4
Weight for member function of MAXDiff for S class in fuzzy logic
scheme
MaxDiff_weightS 0.4
Weight for member function of ETOP for C class in fuzzy logic
scheme
EtopPar_weightC 0.15
Weight for member function of ETOP for S class in fuzzy logic
scheme
EtopPar_weightS 0.15
Weight for member function of VILDiff for C class in fuzzy logic
scheme
VilDiff_weightC 0.15
Weight for member function of VILDiff for S class in fuzzy logic
scheme
VilDiff_weightS 0.15
Radius for MAXDiff and VILDiff determination (km) ConvRadius 11
Code for convective pixels (between 1 and 255) CodeC 2
Code for stratiform (non-convective) pixels (between 1 and 255) CodeS 1
Input data
Table 2. The list of the algorithm input data (selected empirically).
Input data Units Description
Weather radar products
Maximum of reflectivity (Z) dBZ Product: MAX(Z) – Maximum. Display range of height:
1–15 km
Height of radar echo top (ET) km Product: EHT(Z) – Echo Height. Echo threshold: 4 dBZ
Water content in atmosphere
(VIL)
mm Product: VIL – Vertically Integrated Liquid. Range of
height: 1–10 km
Weather radar-based
parameters
Difference of reflectivity (ΔZ =
Zmax / Zmean)
dBZ Calculated from MAX(Z) radar product
Difference of VIL (ΔVIL = VIL / mm Calculated from VIL radar product
33
VILmean)
Meteorological satellite
products
Cloud Type (CT) (classes) EUMETSAT product
Overshooting Tops (OTS) K EUMETSAT product
Lightning detection system
products
Cloud-to-ground lightning (CG) (number) Calculated from reports generated every 1 minute that
include data about each lightning
Numerical weather prediction
products
Convective Available Potential
Energy (CAPE)
J kg-1
Based on thermodynamic diagram
Total Totals Index (TTI) °C Based on thermodynamic diagram
The radar data are mandatory for the algorithm correct running. The two options of
input data set are available:
• option standard: using only radar data as input (five first parameters from
Table 2),
• option standard+: using all set of input data (Table 2) - to be implemented.
Separation of convective and non-convective precipitation
The identification of convection areas is performed by fuzzy logic approach, which is
applied to categorize each radar pixel into convective or non-convective precipitation
(classes: non-convective S, or convective C). For the both classes membership
functions are defined for all selected parameters. Then the functions are aggregated
as weighted sums:
where: x is the precipitation class (S or C); i is the parameter number; n is the number
of the parameters; Pxi is the membership function for i-th parameter; Wxi is the
weight of i-th parameter. Comparison of the weighted sums for both classes decides
which category S or C a considered radar pixel belongs to.
The membership functions were determined on Polish meteorological data set from
2007 and 2013. The whole data set was labelled by hand as convective or non-
convective areas, which was done by meteorologist from forecast office as a human
expert. In this way two data subsets were created with all parameter values, and
then membership functions were empirically established for all parameters.
34
Two kinds of the functions were employed: one- and two-dimensional (1-D and 2-D),
the latter for the parameters that are calculated from two other ones (i.e. ΔZ and
ΔVIL).
The 1-D membership functions were obtained from analyses of scatter diagrams for
the particular parameters (Fig. 1), which allowed to determine threshold values
above or below which the values of relevant membership functions are attributed to
0 or 1, and linear or another approximation of the function values within the range
(0, 1).
35
Fig. 1. One-dimensional membership functions for convective (on the left) and stratiform (on
the right) precipitation.
The 2-D membership function is defined not for single parameter but for two
parameters analysed jointly: (ΔZ, Z) and (ΔVIL, VIL). Membership functions for C and S
classes were determined in dependence on certain percentiles empirically estimated
on historical data. The uncertainty area was assumed to lay between 5% and 25%-
percentiles of all parameters’ pairs gathered in appropriate data subset, as it is
presented in Fig. 2. For values below 5% and above 25%-percentile values of
membership functions were assigned to 0 and 1 respectively, whereas for values
between 5% and 25%-percentile values of membership function are linearly
interpolated in range from 0 to 1 taking distances to the both percentiles into
account. In our case for two investigated 2-D membership functions it turned out
36
that 5%-percentiles for convective and non-convective classes are so close each other
that they were approximated by the common one.
Fig. 2. Two-dimensional membership functions for ΔZ (on the left) and ΔVIL (on the right).
Quality characterization
Map of quality index (QI) will be calculated for the output field. The QI will be
determined based on comparison of PC and PS - sums of membership functions for
thw two classes: convective and non-convective precipitation.
Example
Example of radar reflectivity field in dBZ (on the left) and detected area of convective
and stratiform precipitation (on the right) for Legionowo radar (12 August 2007, 14
UTC):
Output
Data type using ODIM notation where possible, e.g. DBZH
Output quantity CLASS (convective/non-convective precipitation) as IMAGE object (in
Cartesian coordinates) with:
• "how": task - "pl.imgw.product2d.convection",
• "how": task_args - parameters of CONVECTION algorithm.
Quality index (QI) field
Quality index field QIND as IMAGE object with:
• "how": task - "pl.imgw.product2d.convection",
• "how": task_args - parameters of CONVECTION algorithm.
References
37
− Scientific paper: Jurczyk, A., Szturc, J., and Ośródka, K., 2012. Convective cell
identification using multi-source data. IAHS Publ., no. 351, 360-365.
4. Quality-related data processing
For the 3D volumes (PVOL in ODIM denotation) postprocessing a set of quality algorithms has been
designed and developed, which are dedicated to the data corrections. As a result the corrected
(quality enhanced) volumes with related quality information (as quality index, QI) can be used for
generation of more reliable 2D products. The quality algorithms for volume postprocessing are
available in BALTRAD toolbox.
4.1. Brief catalogue of quality algorithms for 3D reflectivity data volumes
4.1.1. Removal of geometrically-shaped non-meteorological echoes and quality characterization
(as a part of RADVOL-QC package) – RADVOL-QC: SPIKE
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
ODIM metadata requirements for I/O
� Dataset-specific “what”: gain, offset, nodata, undetect.
� Dataset-specific “where”: elangle, nbins, nrays, rscale.
Input data
object=PVOL or SCAN; quantity=DBZH, otherwise TH.
Short description
The spurious echoes from sun and external interference, so called spikes, are characterized
by their spatial structure that clearly differs from precipitation field pattern. The shape of
such echo is very specific: it is similar to a spike along the whole or large part of a single or a
few neighbouring radar beams. Reflectivity field structure is investigated to detect such echo
on radar image in this algorithm, which identifies spikes, cuts them out from the precipitation
field, and replaces by proper reflectivity values.
In the algorithm two stages of spike removal are introduced: for “wide” (subalgorithm A) and
“narrow” (subalgorithm B) types of spikes.
Output
Data type using ODIM notation where possible
Corrected DBZH, with "pl.imgw.radvolqc.spike" added to data-specific "how"/task,
and the algorithm parameters added to "how"/task_args.
Quality index (QI) field
Quality index (QI = 0 for bad data, QI = 1 for excellent data) with
"pl.imgw.radvolqc.spike" in quality-specific "how"/task, and the algorithm
parameters in "how"/task_args.
4.1.2. Removal of non-meteorological echoes and quality characterization – RADVOL-QC: NMET
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
38
ODIM metadata requirements for I/O
� Top-level “where”: height.
� Dataset-specific “what”: gain, offset, nodata, undetect.
� Dataset-specific “where”: elangle, nbins, nrays, rscale.
Input data
object=PVOL or SCAN; quantity=DBZH, otherwise TH.
Short description
In the detector two stages of non-meteorological echo removal are introduced: for “low”
(subalgorithm A), and “high” (subalgorithm B) types of the echoes.
Output
a) Data type using ODIM notation where possible
Corrected DBZH, with "pl.imgw.radvolqc.nmet" added to data-specific "how"/task,
and the algorithm parameters added to "how"/task_args.
b) Quality index (QI) field
Quality index (QI = 0 for bad data, QI = 1 for excellent data) with
"pl.imgw.radvolqc.nmet" in quality-specific "how"/task, and the algorithm
parameters in "how"/task_args.
4.1.3. Removal of measurement noise and quality characterization – RADVOL-QC: SPECK
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
ODIM metadata requirements for I/O
� Dataset-specific “what”: gain, offset, nodata, undetect.
� Dataset-specific “where”: elangle, nbins, nrays, rscale.
Input data
object=PVOL or SCAN; quantity=DBZH, otherwise TH.
Short description
Generally, the specks are isolated radar gates with or without echo.
Output
Data type using ODIM notation where possible
Corrected DBZH, with "pl.imgw.radvolqc.speck" added to data-specific "how"/task,
and the algorithm parameters added to "how"/task_args.
Quality index (QI) field
Quality index (QI = 0 for bad data, QI = 1 for excellent data) with
"pl.imgw.radvolqc.speck" in quality-specific "how"/task, and the algorithm
parameters in "how"/task_args.
4.1.4. Quality characterization due to distance to radar related effects – RADVOL-QC: BROAD
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
39
ODIM metadata requirements for I/O
� Top-level “how”: beamwidth, pulsewidth.
� Dataset-specific “what”: gain, offset, nodata, undetect.
� Dataset-specific “where”: elangle, nbins, nrays, rscale.
Input data
object=PVOL or SCAN; quantity=DBZH, otherwise TH.
Short description
The horizontal and vertical broadening of radar beam for each gate can be computed when
its polar coordinates are known: elevation angle, azimuth angle, and radial distance to radar
site in km, and two parameters of radar beam: beam width and measurement gate length in
km calculated from radar pulse length.
Output
a) Data type using ODIM notation where possible
-
b) Quality index (QI) field
Quality index (QI = 0 for bad data, QI = 1 for excellent data) with
"pl.imgw.radvolqc.broad" in quality-specific "how"/task, and the algorithm
parameters in "how"/task_args.
4.1.5. Correction of partial and total beam blockage and quality characterization including ground
clutter – RADVOL-QC: BLOCK
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
ODIM metadata requirements for I/O
� Top-level “where”: height.
� Top-level “how”: beamwidth.
� Dataset-specific “what”: gain, offset, nodata, undetect.
� Dataset-specific “where”: elangle, nbins, nrays, rscale.
Input data
object=PVOL; quantity=DBZH, otherwise TH.
Short description
A geometrical approach is applied to calculate the degree of the beam blockage.
Output
a) Data type using ODIM notation where possible
Corrected DBZH, with "pl.imgw.radvolqc.block" added to data-specific "how"/task,
and the algorithm parameters added to "how"/task_args.
b) Quality index (QI) field
Quality index (QI = 0 for bad data, QI = 1 for excellent data) with
"pl.imgw.radvolqc.block" in quality-specific "how"/task, and the algorithm parameters in "how"/task_args.
40
4.1.6. Correction and quality characterization for attenuation in rain – RADVOL-QC: ATT
Authors
Katarzyna Ośródka, Jan Szturc, Anna Jurczyk
Institute of Meteorology and Water Management – National Research Institute
ODIM metadata requirements for I/O
� General “what”: source(NOD).
� Dataset-specific “what”: gain, offset, nodata, undetect.
� Dataset-specific “where”: nbins, nrays, rscale.
Optional:
� General “how”: wavelength (needed if parameters ATT_a and ATT_b do not exist in XML
parameter file).
Input data
object=PVOL or SCAN; quantity=DBZH, otherwise TH.
Short description
Reflectivity-based algorithm is used iteratively (“gate by gate”) for correction of attenuation
in rain.
Output
a) Data type using ODIM notation where possible
Corrected DBZH, with "pl.imgw.radvolqc.att" added to data-specific "how"/task, and
the algorithm parameters added to "how"/task_args.
b) Quality index (QI) field
Quality index (QI = 0 for bad data, QI = 1 for excellent data) with
"pl.imgw.radvolqc.att" in quality-specific "how"/task, and the algorithm parameters
in "how"/task_args.
4.1.7. Polarimetric rain attenuation correction : rainATTENcorrect
Authors
Rashpal S. Gill and Martin B. Sørensen
Danish Meteorological Institute
1. Algorithm name
Rain attenuation correction of reflectivity an differential reflectivity: PolRainAttCorr
2. Basic description
A number of methods have been proposed in the literature for correcting ZHH for rain
attenuation (Bringi el. al., 1990, Carey et al., 2000, Tesud et. al., 2000, Bringi et al., 2001).
Describing each one of these is beyond the scope of this report. However, it is suffice to state
that from an operational point of view, the so-called “Linear ФDP with a fixed linear α”, by
Bringi et. al., (1990) is preferred as it is easy to implement in real-time and is not too
demanding computationally. However, its main dis-advantage is that it can over or under-
estimate attenuation. In the current version of the software, this method has been
implemented to correct for the attenuation suffered by ZHH and ZDR in rain.
3. Computational procedure
41
Similar to computing KDP, correcting ZHH and ZDR for rain attenuation is rather challenging as
the underlying ФDP(r) are very “noisy” i.e., generally contain many outliers. The current
method used at DMI was inspired by Bringi et. al. (2005) and involve the following steps:
1. Compute the texture of ФDP, Tex( ФDP(x,y)), using equation (2).
2. Generate range mask based on thresholds for Tex(ФDP(x,y)threshold), Signal-to-Noise Ratio
(SNRthreshold) and ρHVthreshold to remove bad ФDP values.
3. Interpolate ФDP across “bad” data segments.
4. Compute the ФDP(0) i.e., offset at the “origin” by averaging the first N range gates FDP
containing precipitation.
5. ФDP(r) is then smoothed using a median filter with a window size of ~ 5.0 km - 6.5 km.
6. Correct both ZHH and ZDR for rain attenuation using equations (13) and (16), respectively.
4. Theoretical background
For an inhomogeneous path, i.e. Ah varies along the path, the corrected ZHH (units of dB) is
related to the measured measured ZHH at range r from the radar by the following expression
Substituting equation (10) into the above expression and assuming a is constant we get
Now substituting for KDP from equation (1), the following expression is obtained for the
corrected ZHH
Thus knowing by how much ФDP increases from its value at the origin ФDP(0) it is possible to
correct the radar reflectivity, ZHH,
Radar differential reflectivity rain attenuation correction
Just like the above radar horizontal reflectivity, ZHH , the differential reflectivity also suffer
from rain attenuation, especially at C- and X-bands. To estimate the rain attenuation of ZDR,
we repeat the above procedure for ZHH. We get in this case the following expression
where ADP is the difference between the specific attenuations between the horizontally and
vertically polarized waves, i.e., ADP = AH - AV , and is normally referred to as the specific
42
differential attenuation. By analogy to equation (10) a linear relationship between ADP and
KDP has been proposed (Bringi et. al., 1990) i.e.,
Substituting equation (15) into (14) we get the following expression for the corrected ZDR
The coefficient β is typically 0.01-0.003 at C-band (Bringi et. al., 2005).
References
� Bringi V. N., Chandrasekar N., Balakrishnan and Zrnic D. S., 1990, ”Anexamination of
propagationeffects in rainfall on radar measurements at microwave frequencies”, J.
Atmos. Oceanic Tech.,vol., 7, 829 – 840.
� Bringi, V. N., Chandrasekar, V.: 2001, ”Polarimetric Doppler Weather Radar”, Cambridge
Univ.press, Cambridge, UK.
� Bringi V. N., Thurai R., and Hannesen R., 2005, “Dual-Polarization Weather Radar
Handbook”,AMS-Gematronik GmbH.
� Carey L. D., Rutledge S. A., Ahijevych D. A., and Keenan T. D., 2000, “ Correcting
propagationeffects in C-band polarimetric radar observations of tropical convection using
differential propagationphase”, J. Appl. Meteor., vol. 39, 1405 – 1433.
Short description
A number of methods have been proposed in the literature for correcting ZHH for rain
attenuation. Describing each one of these is beyond the scope of this report. However, it is
suffice to state that from an operational point of view, the so-called “Linear ФDP with a fixed
linear α” is preferred as it is easy to implement in real-time and is not too demanding
computationally. However, its main disadvantage is that it can over or under-estimate
attenuation. In the current version of the software, this method has been implemented to
correct for the attenuation suffered by ZHH and ZDR in rain.
4.2. Brief catalogue of quality algorithms for 3D Doppler data volumes
4.2.1. Dealiasing radial winds
Authors
Günther Haase
Swedish Meteorological and Hydrological Institute
ODIM metadata requirements for I/O
nbins, nrays, gain, offset, nodata, undetect
Input data
Polar volume or scan
43
Short description
The algorithm detects abrupt velocity changes between neighboring measurements and
eliminates (multiple) folding.
Output
VRAD
References to quality algorithms
Bringi, V.N., Chandrasekar, N., Balakrishnan, and Zrnic, D. S., 1990. An examination of propagation
effects in rainfall on radar measurements at microwave frequencies, J. Atmos. Oceanic Tech.,
7, 829 – 840.
Bringi, V.N., Chandrasekar, V., 2001, Polarimetric Doppler Weather Radar, Cambridge Univ. Press,
Cambridge, UK.
Bringi, V.N., Thurai, R., and Hannesen, R., 2005. Dual-Polarization Weather Radar Handbook, AMS-
Gematronik GmbH.
Carey, L.D., Rutledge, S.A., Ahijevych, D.A., and Keenan T.D., 2000. Correcting propagation effects in
C-band polarimetric radar observations of tropical convection using differential propagation
phase, J. Appl. Meteor., 39, 1405 – 1433.
Haase G. and Landelius T., 2004: De-aliasing of Doppler Radar Velocities Using a Torus Mapping. J.
Atmos. Oceanic Technol., 21, 1566-1573.
Michelson, D.B., Lewandowski, R., Szewczykowski, M., Beekhuis, H., 2009. EUMETNET OPERA
weather radar information model for implementation with the HDF5 file format. OPERA
Working Document WD_2008_03.
Ośródka, K., Szturc, J., Jurczyk, A., 2012. Chain of data quality algorithms for 3-D single-polarization
radar reflectivity (RADVOL-QC system). Meteorol. Appl. (Early view).
Szturc, J., Michelson, D., Koistinen, J., Haase, G., Plura, M., Gill, R., Sorensen, M., Ośródka, K., Jurczyk,
A., 2012a. Data quality in the BALTRAD+ project. Proc. 7th European Conference on Radar in
Meteorology and Hydrology ERAD 2012, Toulouse, France (CD).
Szturc, J., Ośródka, K., Jurczyk, A., 2012b. Quality control algorithms applied on weather radar
reflectivity data. In: Doppler Radar Observations – Weather Radar, Wind Profiler, Ionospheric
Radar, and Other Advanced Applications, (Eds. J. Bech and J. L. Chau), InTech, 289–306.
4.3. Total quality characterization
Part of the quality algorithms apart from corrections generates quality index QI fields that represents
quality related to particular quality factors. In order to obtain total QI field characterizing quality
because of all factor, another algorithm should be applied.
4.3.1. Total quality index (QI) for scans/volumes – QI_TOTAL
Basic description
Physical basis of the algorithm
Integration of quality indices generated by all or selected quality algorithms.
Amount of validation performed so far
Not developed yet.
References (names and contact information of all developers during the evolutionary history,
scientific papers)
IMGW, Department of Ground Based Remote Sensing.
ODIM metadata requirements for I/O
� General “what”: source(NOD).
44
� Dataset-specific “what” for QI data: gain, offset, nodata, undetect.
� Dataset-specific “where” for QI data: nbins, nrays.
Input data
What kind of radar data (including the list of previous algorithms and quality flags applied)
object=PVOL or SCAN; quantity=QIND (QI information generated by particular quality
algorithms).
Other data (optional and mandatory, applying “universally” agreed formats, geometry)
None.
Logical steps, using any of: text, flow charts, graphics, equations (or references to equations),
conditional branches in “all possible cases”.
Quality Index (QI) definition
Quality index QI is a unitless quantity with values in the range from 0 to 1, where: QI
= 0 for bad data, QI = 1 for excellent data.
Algorithm parameters
Set of the algorithm parameters:
Description Denotation Available options Default
value
List of QI fields QIFields Example: “pl.imgw.radvoqc.att,
pl.imgw.radvolqc.spike”;
NULL means all available QI
fields
NULL (all
available)
Methods of
combination of
particular QIs into
total QI
Method multi / add / min multi
Overwrite if total QI
already exists
Overwrite 0 (no) / 1 (yes) 0
At first the XML file is checked whether there exists group for a considered radar
(based on the radar name read from "what"/source(NOD)), which contains the
algorithm parameters. If "yes", then parameters are read from that XML group, but if
it is impossible for a particular parameter, then default value from source code is
taken. If the group does not exist, parameters are read from <default> group in XML
file in analogous way.
If the algorithm is run by means of BALTRAD toolbox then all the algorithm
parameters for each specific radar should be placed in relevant XML file by the
BALTRAD system admin. Default parameters are placed in the file by admin as well.
Moreover, the algorithm default parameters are also included in software.
Computation
Total quality index is generated from all or selected quality indices earlier generated
by BALTRAD quality algorithms. It constitutes the final stage in data volumes
processing.
The total QI is generated:
� from all QI fields available in quality fields (quantity=QIND),
� from QI fields selected for particular quality algorithms ("how": task).
45
If there are no available particular QI fields then total QI is not generated. If a given
pixel is marked as "nodata" value at least in one of QI fields then "nodata" is assigned
to total QI as well.
The following methods for the QIs combination are to select:
� multi (multiplicative)
� add (additive)
� min (minimum value)
where i = 1, …, n; n is the number of particular quality indices.
Output
a) Data type using ODIM notation where possible, e.g. DBZH
No changes.
b) Quality index (QI) field
Total quality index QI with:
� "pl.imgw.qi_total" in quality-specific "how": task,
� combination method and the particular contributing QIs listed in "how":
task_args.
5. Data visualization
5.1. BALTRAD WMS
Authors
Tuomas Peltonen, Juhani Lahtinen
STUK
Basic description
Web Map Service
WMS (Web Map Service) is a standard protocol for serving georeferenced images
over the Internet developed and published by the Open Geospatial Consortium
(OGC). Images are generated on the server side. There are available a lot of software
that has support for WMS. Examples include OpenLayers for Web browser usage and
Quantum GIS for desktop usage.
Technical description
Software is independent of BALTRAD node. Only ODIM HDF5 or GeoTIFF files are
needed for data input. Software consist of Python scripts based on Mapserver
software. The main program is the visualization script which runs via Web server.
There is also data converter script that converts from HDF5 files to GeoTIFF raster
images. Installation instructions are included in the GIT repository.
Metadata requirements
Projection must be defined in ODIM metadata.
The software has also support for FMI Open data.
Output
Output for WMS clients
Mapserver supports many different output formats that can be requested via WMS
client.
Georeferenced GeoTIFF images
Geotiff images can also be downloaded using the software. These images can be
useful if are viewed or edited in a GIS software.
46
KMZ files
Software also has capability to generate KMZ files that can be viewed in Google
Earth. It is possible to create a KMZ file with either a single image or time series.
Example of usage in (STUK)
Software is integrated into the collaborative emergency management software "TIUKU" and
dose-rate monitoring network web interface "USVA". The integration allows viewing of radar
images together with dispersion model or measurement results.
6. Abbreviations
2D – two-dimensional
3D – three-dimensional
ACL – application case logs
ATC – air traffic control
CAPPI – constant altitude plan position indicator (standard radar product)
ETOP – echo top (standard radar product)
IMAGE – 2-D Cartesian image (file object)
LAWR – local area weather radar (type of weather radar)
MAX – maximum of reflectivity (standard radar product)
NWP – numerical weather prediction
ODIM – OPERA digital information model
PPI – plan position indicator (standard radar product)
PVOL – polar volume (file object)
QI – quality index
QIND – quality index (quantity identifier)
R – precipitation rate/accumulation
SCAN – polar scan (file object)
SRI – surface rainfall intensity (standard radar product)
V – wind data (velocity and direction)
47
VAD – velocity azimuth display (standard radar product)
VIL – vertically integrated liquid water (standard radar product)
VVP – volume velocity processing (standard radar product)
Z – radar reflectivity
7. References
Michelson, D. B., Lewandowski, R., Szewczykowski, M., Beekhuis, H., 2011. EUMETNET OPERA
weather radar information model for implementation with the HDF5 file format, Version 2.1.
OPERA Working Document WD_2008_03.
Szturc, J., Ośródka, K., Jurczyk, A., Maksym, J., 2009. Definition of the target end-users. BALTRAD
Project document W701.
Szturc, J., Ośródka, K., Jurczyk, A., Maksym, J., 2010. The end-users requirements and expectations.
BALTRAD Project document W702.
Szturc, J., Ośródka, K., Szewczykowski, M., Jurczyk, A., Lahtinen J., 2012. Report on Application Case
Log. BALTRAD Project document W703 (see also BALTRAD project webpage:
http://baltrad.eu/what-baltrad-offers-you).
Szturc, J., Ośródka, K., Jurczyk, A., Lahtinen, J., 2012. Draft of catalogue of radar-based products
which end-users are interested in. BALTRAD Project document W402.
Recommended