Radar and Lidar Data Processing

1.1Radar and Lidar Data Processing

The proliferation of ‘legacy’ data formats is also a significant challenge. Over the years many different formats have been developed by instrument developers, and frequently the user spends a large fraction of the available research time moving data around and trying (and often failing) to convert it into a form that is useful. In preparation for the proposed work, a new common data exchange format for lidar and radar was developed, along with the required format translation software for several commonly use data formats.

An important aspect of this work is to help facilitate research into the assimilation of radar and lidar data into numerical models. Accurate initial conditions are critically important for weather and climate research, and remote sensing instruments are among the few that can provide high-resolution, three-dimensional wind, aerosol, and precipitation fields. Current data assimilation techniques are limited in their ability to ingest large amounts of radar or lidar data, and significant data pre-processing such as quality control and data thinning is required. The optimal way to assimilate radar and lidar data into models is an ongoing area of research that is hindered by the lack of mature processing tools.

Figure 1 (below) shows a high-level view of the data flow for an end-to-end system incorporating radar and lidar instrumentation. Doppler radar data at its most raw is in the form of what is referred to as ‘time series’, with 2 values (so-called ‘I’ and ‘Q’) for each gate and each pulse. This is very voluminous data and in the past was usually discarded due to limited storage capacity. Some modern systems provide the option of saving this data for detailed analysis and display. From the I/Q time series, the radar ‘moments’ are computed, for example reflectivity (zero-th moment), velocity (first moment), and spectrum width (second moment). Lidars generally do not export time series data, instead treating moments as their ‘raw’ data.

Radars and lidars produce raw data that are inherently ‘noisy’ and contains artifacts and errors that must be handled before it is useful for either scientific or operational purposes. One can think of the processing steps as distilling the real information from the raw data. Generally these steps are applied to data still in the native coordinates. Spurious non-weather echoes from the ground, birds, wind-farms and the like must be identified and dealt with. Clutter mitigation, interference and artifact removal may be carried out. Velocity and range ambiguity problems (referred to as ‘aliasing’) are inherent to radars and lidars, which sometimes lead to uncertainty about where the echo is located or at what velocity the scatterers are moving. Therefore, ‘de-aliasing’ algorithms may be applied as appropriate. Also at this stage, data quality metrics may be computed – these are necessary to remove bad data for analysis, or to supply estimates of uncertainty that are required by numerical model data assimilation systems. Once these steps have been applied, the data can be considered ‘quality controlled’. Algorithms that operate in polar coordinates may be applied at this stage, and the data may be forwarded to models for data assimilation.

Figure 1: High-level data flow for modern end-to-end analysis of radar and lidar data.

For many applications the data must be transformed from polar to Cartesian coordinates. As a result of the complicated geometry of the propagation paths of electromagnetic pulses through the atmosphere, coupled with the moving coordinates for mobile instruments, sophisticated processing is required to correctly geo-reference the observations. There are a number of different approaches for interpolation and coordinate transformation, and a suitable method must be chosen. Once the data is in Cartesian coordinates, the results of numerical models may be imported, and algorithms appropriate to Cartesian data may be run.

As these systems become more complex and scientists wish to use the data in a wider context, for example in climate research, external environmental data sets (e.g. surface observations, soundings, satellite data) must be imported and integrated with the products from the radar/lidar analysis.Visualization of the results of the analyses at various stages of the processing chain requires that suitable displays be available for each stage and for different data types. While most people are familiar with the classic “radar scope”, the variety and complexity of modern radar products requires more sophisticated software displays.

The goal of this project is to significantly improve the radar and lidar data processing capability for the community. Determining what functionality is most desired by the user community is a significant task due to many diverse research interests. A white paper developed in 2012 was presented to NSF and circulated widely to the radar and lidar user community at universities and government laboratories. This white paper was distributed prior to a workshop hosted by NSF from 27-29 November 2012 in Boulder, CO, titled Community Workshop on Radar Technologies. During one of the workshop sessions the attendees (users) were asked to consider and prioritize their urgent software needs, both for their personal research and what they thought would be best for the broader community. Table 1 summarizes the outcome of the survey, ranked according to highest need.

It is clear from the NSF supported workshop and feedback from the white paper distribution that there is a strong need for improved software infrastructure in the radar and lidar community (Bluestein et al. 2014). The work in this proposal would meet that need by improving existing time-tested software and developing new open-source infrastructure, data exchange formats and displays, and algorithm implementations.