Prototype of integrated radar sampling.

Oct 16 2007

http://www-sdd.fsl.noaa.gov/~ramer/noaa/integRadarSamp/integRadarSamp.html

There is a desire to be able to get additional environmental data when sampling radar. The ideas originally discussed for this capability have focused on replicating the functionality of the satellite cloud height sampling function. While one can understand why that idea would be attractive, the cloud height sampling does have some drawbacks that make it a less than ideal approach for this task.

First, the vertical position of the cloud top is highly variable in space and time, whereas the location of a radar cone is well defined; whatever is done for integrated radar sampling should take advantage of that fact. Second, the cloud height sampling is based on the addition of a great deal of special case code to the satellite depictable, making it hard to maintain. The radar depictable is already very complicated and it would be a good idea to avoid adding another layer of complexity to it. Third, the cloud height sampling has very limited configurablity. One can configure somewhat which data sources are used, but there is no configurability at all in what parameters are output. Finally, one of the centerpieces of the cloud height sampling is the pop-up skewt, which creates noticable delays in the sampling response, especially in four panel mode. This would likely make it of limited utility in warning situations.

Even though there are problems with using the cloud height sampling function as the foundation of the integrated radar sampling, this does not mean that some of its features cannot be made available in the context of radar data. More on this later.

We have implemented an alternate approach to the integrated radar sampling which addresses these issues. Here we will discuss this alternate approach and show some screen shots of the initial implementation. We realize that this is a divergence from the requirements as literally written, which is exactly why this information was first presented so early.

Here is an initial cut of the user interface for the selectors that control the integrated radar sampling. There is certainly no reason that they would have to reside here. Be aware that for the purpose of the dual polarization upgrades there will be some reorganization of the radar menus. In conjunction with this, it is likely that we will consider other approaches for implementing the environmental data sampling selectors.



What follows is a screen shot of 0.5 Z/V with the current default radar sampling activated. Note that this is already a subtantial amout of text being output; in four panel mode it can be overwhelming. Thus, this proposed implementation of the integrated radar sampling does not output the additional environmental data by default.



The next screen shot show what results from selecting the "RUC40 Std Env Data Package" as an overlay. Note that there are new legends, and the sampling is now showing wind, temperature, and dewpoint in addition to what was being shown before. Also note that there is no data being shown for the overlays, they just sample. If there was a desire to not sample a particular variable, it could be toggled off. If there was a desire not to see that whole stack of legends, one could always use the enter key to rotate the legends to just show the frame times, as is often done with families. The id associated with the sample string defaults to the id for that variable in the virtual field table, but that is configuable. For temperature it is the default, for dewpoint is has been configured to be Td instead of DpT, and for wind the id has been suppressed.



At this point we will discuss exactly what these "Environmental Data Packages" are. Several new core features are needed in the D-2D to support the existence of the Environmental Data Packages. They are:

   * The ability to designate contour and wind barb gridded data
     overlays as sampleable.
   * The ability to choose a display density of zero (near zero, in
     actuality), which means display nothing.
   * A new level type in the volume browser, radar tilt.
   * A new function in the volume browser that can compute the height of
     a given radar tilt for the "Home" radar.
   * The ability to temporarily override which radar is the "Home" radar
     based on what radar data is currently loaded in the display.
   * The ability to do space loads of radar tilt levels in the volume browser.
   * The ability to create multi-loads out of space load displays in the
     volume browser.
   * The ability to specify a default density for a multi-load.
   * The ability to automatically segregate a space load overlay on a four
     panel into separate overlays.
   * Time matching in four panel mode can now be sensitive to the first
     overlay in a panel, not just the first overall.
   * More rigorous handling of vertical levels in time matching.
Note that less than half of these new capabilities have anything to do with radar per se. Thus, it is hoped that in the future these capabilities could be leveraged for other things.

So, what is an Environmental Data Package? It is a multi-load of one or more all-tilts space loads of model data from the volume browser. Such a multi-load has been designated as having a default density of zero, and the individual products in the multi-load have style entries such that they are sampleable. These multi-loads are not hardwired; they are based on entries in the virtual field table, and they are automatically posted to the main menu, in very much the same manner that families are. What follows is the specific virtual field table entry that supports this initial prototype Environmental Data Package:

EnvPkg0| |N|Std Env Data Package | |OTHER | | \
 *MultiLoad,Layer|1.|T,spatial-TILT|1.|DpT,spatial-TILT \
                 |31.|Wind,spatial-TILT \
                 |2.|3.|4.|5.|-0.000001
If there was a desire to have additional variables be sampleable in this manner, one could either add more variables to the package, or add more packages. In theory, anything one can compute in the volume browser could be put in a package. All the products that make up these packages are also displayable directly from the volume browser, but in that case graphics would initially be shown by default. Furthermore, suppose one actually wanted to see a display of one of the fields in a package. This could be done with a third button popup on the legend, changing the density to something other than zero, as follows:


yielding the following display:



If one overlays a package on a four panel, then data for the appropriate tilt will get matched in each panel; the package would only get confused if one mixed tilts in a panel. The packages correctly match with an all-tilts as well. The package can even be sensitive to which radar is in each panel, as follows:



Recall from the first screen shot that the first item on the menu entitled Env was called Radar Popup Skewt. If one overlays this on radar data, then one gets access to the same popup skewt functionality as used in the satellite cloud height sampling.



Note that this does not change what results from sampling, it just drives the popup skewt. Instead of turning an internally held satellite temperature into a height based on a sounding, the height is computed based on knowledge of which radar is in the display and where the cursor is. Since the details of the internally held radar data are not needed to make this work, there is no need to replicate the complex popup skewt logic in the radar depictable. For this prototype, the satellite depictable was modified such that if it had no data keys, it would do a radar based height computation. As such, the Radar Popup Skewt overlay is a satellite depictable, even though it carries nor displays any satellite data. Furthermore, for the Radar Popup SkewT, the skewT is enableed as soon as a data source is selected, thought it is still true that the skewT will not appear until after a sampling action is taken.