# OPERA the Radar Project
## 2 Materials and Methods
### Central Processing and Quality Control  
In the early years, OPERA was focused on supporting bi-lateral data exchanges. In 2006, OPERA took a first step towards an operational service with the OPERA Pilot Data Hub, which received single-site Cartesian products and national composites from members to create a 4 km resolution pan-European composite. Variability in the quality of the input was surprisingly large, and the re-projection of each of the Cartesian product into the pan-European one led to the loss of resolution and discontinuities. In order to create a better product, it was decided that a data center was needed to receive all the Plan Position Indicator (PPI) scans produced by the European radars, instead of national composites, and, in 2011, the Opera Data Centre (ODC) (later called \"Odyssey\") was created. In order to make a composite product that is as homogeneous as possible, the idea (at first) was for each country to send raw polar data scans with only the noise removed and to implement the best quality control methods centrally, in order to apply the same quality control to each radar scan. Figure 1: Location and type of radars included in the Operational Program for Exchange of Weather Radar Information (OPERA) composite. A common definition for dry pixels was needed and two terms were defined: Nodata is used to describe that the pixel is out of range or in a blanked sector. Undetect means that the received radar signal is at or below noise level. The first two central methods to be implemented were an anomaly-removal module [6] and a hit-accumulation filter [7]. The anomaly-removal module uses computer vision methods to identify the patterns (e.g., straight lines or single pixels) that are most often associated with sources not related to weather. The module defines a probability of precipitation that was added to the meta-data as a first quality indicator and rejects the non-precipitation pixels by setting values that exceed a threshold to nodata. The hit-accumulation clutter filter uses a normalized echo count (also called occurrence frequency) calculated each month. In each radar scan, the filter identifies all the pixels for which the normalized echo count exceeds a threshold as residual clutter. A value of 0.6 is typically used. Two additional methods were implemented in late 2015: Beam blockage correction and a satellite-based filter of residual non-precipitation echoes. The beam blockage correction is described in [8]. The percentage of beam blockage is calculated, in polar coordinates, using a 1 km digital elevation model (GTOPO30) and a geometric propagation model that over-samples the radar beam. For each scan, pre-calculated values are used to correct the reflectivity and are added to the meta-data as a second quality indicator. Reflectivity values in sectors with partial blockage (up to 70%) are corrected and used in the composite products with a lower weight than those in unblocked sectors. Reflectivity values in sectors with blockage exceeding 70% are set to nodata and are not used for compositing. The satellite filter is based on the EUMETSAT Nowcasting SAF [9] Precipitating Clouds product, which is a probability of precipitation. For each radar pixel where an echo is detected, the 49 satellite pixels surrounding are considered. This smudging of the satellite product allows to take into account the time gap between radar and satellite observations and the effects of parallax in the satellite observations. The maximum probability is used as the third quality index. If the probability of precipitation is 0, the reflectivity is set to undetected. A quality indicator, defined by the minimum of the three quality indicators presented above, is also added to the radar meta-data. This compound quality indicator is specially needed for NWP assimilation, which heavily relies on high-quality radar observations to produce better forecasts.