Introduction

This is a continuation of Convert GRIB of Japan Meteorological Agency radar polar coordinates GPV to netCDF (CF / Radial standard). See this article for a description of the CF / Radial conventions.

Meteorological Agency radar polar coordinate data delivered via the Meteorological Agency Support Center, which was handled last time, is provided in real time. However, it does not include the information (polarization parameter) obtained by the dual polarization of the radar. The past data of the dual polarization radar in Tokyo including this polarization parameter is in the form of "weather data provided to grasp the usage needs" [Usage environment of past weather data (FY2)]( It is published on AWS in the framework of https://www.data.jma.go.jp/developer/past_data/index.html). This time I will convert this data to NetCDF (CF / Radial Terms).

About data

Parameters (variable)

Dual Polarized Weather Radar Polar Coordinate Data provides the following 8 variables:

Parameter name	Abbreviation	Parameter number(Actually)	Parameter number(specification)
Horizontal polarization reflection intensity	ref	195	195
Doppler speed	vel	228	2
Doppler speed range	vsw	230	0
Reflex factor difference(Zdr)	zdr	197	197
Phase difference between received signal polarizations(ψdp)	psd	198	198
Rate difference change rate between polarizations(Kdp)	kdp	202	202
Correlation coefficient between polarizations(ρhv)	rhv	199	199
Quality control information	qci	215	206

The parameter numbers in the specifications and the parameter numbers actually stored in GRIB are different, so they are listed together. The spec says that parameter numbers 207-254 are on hold, so it seems that they are simply not listed.

Regarding the reflection intensity, ref (base reflectance) is used in the GRIB file name, but it should be noted that zhh (horizontal polarization reflection intensity) with parameter number 195 is actually stored. This is not a big issue, as they can be considered the same variable in practice.

I will not explain the meaning of variables because this is a technical note, but in Japanese, you should read Fukao and Hamazu (2005) "Radio Remote Sensing of Meteorology and Atmosphere" Kyoto University Press. You can download Full PDF from the Kyoto University Academic Information Repository.

Scan sequence

The scan sequence of Tokyo Radar is shown in the table below.

However, the elevation angle of 90 ° (vertical pointing) of scan number 20 is a scan for correction for polarization radar, but it is performed only for those whose last digit of the time (reference time) is 0, and the last one. Not done if the digit is 5. In other words, once every two volume scans, every 10 minutes.

Therefore, except for scan number 20, the range spacing is constant at 250m.

Scan number	Elevation angle(°)	Maximum range(km)	Range interval(m)	Azimuth spacing(°)
1	25.0	64	250	0.70
2	17.8	64	250	0.70
3	12.8	64	250	0.70
4	9.3	120	250	0.70
5	6.7	120	250	0.70
6	4.8	180	250	0.70
7	3.5	180	250	0.70
8	2.5	400	250	0.35
9	1.7	400	250	0.35
10	1.1	400	250	0.35
11	0.7	400	250	0.35
12	0.3	400	250	0.35
13	0.0	400	250	0.35
14	0.3	250	250	0.70
15	0.3	250	250	0.35
16	0.7	250	250	0.35
17	0.7	250	250	0.70
18	1.3	150	250	0.70
19	2.2	150	250	0.70
20	90.0	64	125	0.70

Changes from conventional radar polar coordinate data

Dual polarization meteorological radar polar coordinate data was dealt with last time [Meteorological Agency radar polar coordinate data](https:: //www.data.jma.go.jp/add/suishin/shiyou/pdf/no13702) and GRIB format are the same, but there are some differences:

--The templates used have changed from 3.50120 to 3.50121 and 4.51022 to 4.51123. --For example, the place where the definition of elevation angle is described from Section 4 (Product Definition Section) to Section 3 (Lattice System Definition Section) has changed.

--Data compression changed from run-length compression (templates 5.200 and 7.200) to simple compression (low compression ratio) (templates 5.0 and 7.0), assuming gzip compression of the entire GRIB.

--In response to the fact that the volume scan takes 10 to 5 minutes, the data is now separated into separate files every 5 minutes.

--The distance between the range and the azimuth was constant, but now there are three types: (250m, 0.7 °), (250m, 0.35 °) and (125m, 0.35 °) (see scan for details). See the sequence table)

--Until now, all scans (elevation angle) were stored in one file for each variable, but now each scan (elevation angle) is stored in a separate file.

-Doppler velocity was previously present in only some of the observed elevation angles, but now it is stored in all elevation angles as well as reflection intensity.

Creating a converter

The same thing as last time, Dual polarization weather radar polar coordinate data format (common to PPI / RHI observation) And CfRadial Data File Format Version 1.4 and just write the code to convert. The changes from the last time are as follows:

--Since it became simple compression, the document section was directly decoded by Python without using wgrib2.

Currently, some challenges remain:

--Change volume scans to be stored together in one NetCDF

--Determine whether to store the quality control information expressed in 8 bits as it is, or to store the variables separately for the results of single polarization system data quality, double polarization system data quality, and selective MTI.

Acknowledgments

--Dually polarized weather radar polar coordinate data is based on the framework of Usage environment of past weather data (FY2) I got it. We would like to thank the people of the Japan Meteorological Agency for fulfilling the request for data disclosure.

[PYTHON] Japan Meteorological Agency Converts GRIB of dually polarized weather radar polar coordinate data to netCDF (CF / Radial standard)