Radar display - blocky, smooth or gradient smooth

[Scott Lincoln]

Tim,

I dont think anyone thinks you are necessarily attacking GR3. Its that we are trying to say that it "smooths" data differently than you think it does. Its not so much a blending or a blurring as the word "smoothing" implies. its an interpolation.

From my understanding of how radar data is retrieved and displayed, it is already messed up to an extent, as the storms are not pixelated. Each radar pixel is actually made up of areas that are higher and lower than what is displayed, it is just kinda averaged for the pixel displayed.

Also in your graph you show the black line cutting off certain colors and changing them. GR3 doesn't change any pixel's color / DBZ in any way.... it just changes how far out it goes from the center of that pixel depending on the neighboring data. That is the same with velocity data. It never changes the intensity of the gate-to-gate. Its not smoothing across the polar scale or lower each of the intensities to make it meet in the middle.
Thats why this type of data interpolation actually has value unlike the "smoothing" in programs like Stormpredator.

 

[Aaron Kennedy]

Fact of the matter: When I'm looking at phenomena that are finer scale than the resolution of the radar, I don't want to look at what an algorithm thinks the storm should look like. I want to see the raw data. Then let ME figure out whether it should be interpolated. I've played with the smoothing on GR2... it makes it much harder to diagnose what reflectivity is doing (for example: advection of hydrometeors in a hook echo).

One place I do have to use smoothing, however, is when I process volume scans to create isosurfaces of reflectivity. We end up using a Barnes weighted adjustment scheme with a radius of influence depending on how far away the storm is from the radar. Without this process, you end up with some nasty looking 3d pictures of supercells ; )

Aaron

 

[Tim Vasquez]

Scott --

Good point -- it sounds like you're saying that GR3 is doing the linear interpolation (as with Graph A in the illustration). If so, then there is no data loss, which is good. I was assuming that it was doing a Graph B smooth.

Some thoughts about the "A" scheme:
* It retains peaks and troughs perfectly, which is great
* It doesn't use a wave function, so it does not accurately model the shape of the storm and has mathematical interpolation (and gradient) errors.
* It's difficult to know which pixel you're looking at actually represents the real data; as stated, the interpolated ones have large mathematical errors

When I get a chance to work with Digital Atmosphere some more I'll have to do some experiments on this.

Tim

 

[Scott Lincoln]

The best way to describe it would be this picture that Mike uses to describe the "smoothing" technique.

http://photoenlargement.imagener.com/

The left picture would be the pixelated non-smoothed, and the middle one is the same technique as used by GR3.
Its obviously not perfect since you cant create resolution where it doesn't exist, but its better than just blurring it. It makes a fairly good representation of what the picture should be.
As always, the interpolation should be taken with a grain of salt, as it is just how the radar sees the storm - same with unsmoothed. Just two different ways of displaying an infinite resolution storm with a finite resolution.

 

[Glen Romine]

I've never understood the aversion to smoothed radar data displays by mets, so long as the center volume data values are preserved. Basically - you just need to use a very small radius for the interpolation to avoid smearing the data center values. There is a suggestion here by some that 'raw' data (of course, we never see the raw data) is 'real', which of course is not true. Real storms aren't digitized. Also, the value reported for each radar volume isn't a clean representation of just the particles within that volume since the pulse power isn't evenly distributed and wholly contained within the volume area that volume value represents, and the further away from the radar the volume is the less representative it is. If you are smoothing a level III radar data set - significant additional pixelation has already been added to the level II data such that I can hardly see where smoothing does any additional harm of note. Unless you are looking at specific data volumes of level II data (in particular, velocity data), I see nothing gained or lost of any real importance regardless of choice.

The only time I can think of where it is really meaningful not to have smoothed display is when you are looking at velocity signatures. I say that not because I think the smoothing corrupts the velocity data if done correctly, but when I'm trying to find the point with the largest shear, it's easier to see with larger regions of the same color next to each other. The meanigfulness of that gate-to-gate shear is often lost (there is a great paper on this topic by Wood and Brown in WAF, 1997) The 'binned' raw data volumes displayed from level II data are convenient for using as a spatial scale - and I miss that when zoomed in with smoothing.

Personally, I don't use smoothing because I don't care for the look of it. I'm just too used to seeing radar data displayed the other way. That said - I don't think it makes a bit of difference for a storm chaser looking to find the general location of a storm, it's intensity, and whether or not a storm has a strong mid-level mesocyclone or not. All of those features will be easy to identify with smoothing or not.

Glen

 

[Ronnie Bradley]

For me, I like smoothing but it all depends on the colour palette used. some palettes make it hard to discern the strength of a storm (break points that are ill-defined). With GRx software, one can write a palette that defines solid colours tied to certain (range of) dBZ's which will give more of a banded appearance. With L3 data, I would probably say that the SolidColor approach (default base reflectivity palette in GRLevel3, for example) would result in the greatest accuracy. When the "Color" attribute is used, then interpolation comes into play. It can also be argued that accuracy with a "color" vs. "solidcolor" based palette can be reduced, especially with L3 data, but is sure makes the data displayed much more attractive .
Now when velocity is concerend, I have that UNchecked on both GR3 and 2. I don't want velocity data interpolated (or smeared) at all.
I do periodicaly uncheck smoothing on both clients to sometimes get a better grasp on a storm.
Examples forthcoming. 1st is the 5/3/1999 Moore / OKC supercell with the new NWS palette which has the "SolidColor" attribute in the palette, unsmoothed.

The same palette with smoothing...

Then there is my "severe weather" palette which has the color (vs solidcolor) attribute. First example is unsmoothed.

Then the smoothed version...

 

[Greg Stumpf]

One issue about smoothing to consider is that there are numerous algorithms out there that can be used to filter data. Gaussian, Cressman, Median, Percent, Scale, Oriented, Erosion, and Dilation filters are examples. Also, kernel size and shape can be varied, as can the the kernel coordinate systems (polar versus cartesian). WDSSII offers many of these varieties of filters to try out (http://www.wdssii.org - free for .edu and .gov).

All of these are going to result in different answers. But for detailed analysis of radar data for NWS warning ops, I prefer to stick with the native unsmoothed data.