RoI calculation (in gridding routine) smear data too strongly, especially vs. z than vs. x and y (physically inconsistent)

[isilber]

Description

The default RoI method DistBeamRoI currently calculates the RoI as follows:

roi = (self.h_factor[0] * ((z - z_offset) / 20.0) +
          sqrt((self.h_factor[1] * (y - y_offset))**2 +
                 (self.h_factor[2] * (x - x_offset))**2) *
          self.beam_factor)

where: self.beam_factor = tan(nb * bsp * PI / 180.) By default, bsp=1.0 (virtual beam spacing) and nb=1.5 (virtual beam width; effectively half a radar's 3-dB beam width).

The main issue: This relates to the RoI calculation: Ideally, each dimension should be weighted equally, but currently, the z dimension has roughly twice the weight of the horizontal dimensions (0.05 vs. tan(nb * bsp * PI / 180.)= 0.026). This inconsistency results in more significant signal smearing in the z dim because the RoI increases faster in that dimension. To my knowledge, this approach does not have a physical basis or justification, but I could be wrong. I understand that this was likely driven by the common use of PPIs (e.g., with NEXRAD) in order to receive a continuous gridded output, especially at large ranges, but this especially biases RHI scans that are commonly in use by ARM, and results in significant loss of information when using ARM radars.

Other issues:

1. The beam width calculation presumably considers a radar's beam width. The default value for nb is 1.5, meaning a beamwidth of 3 degrees. This is exaggerated even for NEXRAD, which has a beam width of ~1 degree (corresponding to nb=0.5) and of course ARM radars such as KaSACR (beam width of 0.33 degrees). This means that data are smeared inconsistent with radar characteristics, and information is lost in gridding.
2. The minimum RoI of 500 m produces too strong smearing, especially at small ranges. I understand, as mentioned previously, that this is likely to enable "capturing" more NEXRAD data points, which have a range resolution of 250 m, but again, this does not conform with other widely used precipitation and cloud radars used by the community.

We should have a solution conforming with Py-ART's primary objective (ostensibly supporting the radar community with an emphasis on ARM). Anyway, below I have an intermediate solution.

Suggested solution (more physically consistent)

1. RoI equation: roi = sqrt(self.h_factor[0] * ((z - z_offset)2 + self.h_factor[1] * (y - y_offset))*2 + self.h_factor[2] (x - x_offset))2) * self.beam_factor)
2. minimum RoI and beam width: a. Interim solution: -nb= 1.(double NEXRAD/X-SAPR beam width; ~6 times Ka/W-SACR beam width; 1.4 times X-SACR,, 2.2 times X-SAPR)
   • min_radius = 250. # m or even better, 100 m given that in short range beams have greater overlap and at long range, the min_radius has no influence as demonstrated below) b. Optimal solution: radar-class based specifications

Below is an example from TRACER showing a "raw" (b1) RHI scan followed by gridding with the current default + RoI, and the suggested solution with the interim solution.

Current default: Suggested solution

[mgrover1]

@isilber - is your suggestion here to change the defaults? Or change the underlying gridding routine?

I think the highlight some good points - a PR here would be more than welcome!! Thanks for raising this issue 👍

[isilber]

@mgrover1, Will do. Wanted to lay the groundwork. The first correction (RoI equation) is essential as it won't survive scrutiny, e.g., in case someone explicitly mentions the calculation in a peer-reviewed publication. The second modification (default inputs) would make the default performance more faithful to the truth as demonstrated above (w/r/t radar resolution and the observed information). By default, the gridding routine uses the "Barnes2" weighting function, which delivers nice results, depending on those input parameters. One can use the "Nearest" option to retain non-smeared radar data. Since "Nearest" also depends on RoI, yet the interpolated values only consider closest values (hence, no data smearing), we can add an optional input scaling factor to the RoI, specifically for that option, which will enable receiving more continuous results without any impact on the Barnes2 interpolation (e.g., a scaling factor of 2 will roughly produce the current default gridding output.