Warn-By-Polygon (OB8.1)
User Interface Working Group


Presented By: Jim Ramer
When: 3 January 2007

GSD Attendees: Tom Filiaggi, Jim Fluke, Joanne Edwards, Leigh Cheatwood, Joe Golden, Woody Roberts, Joe Wakefield, Xiangboa Jing, Susan Williams

Teleconference Attendees: Shannon White, John Ferree, Carl Gorski, Craig Schmidt, Greg Stumpf, Mike Masig, Greg Noonan

The Warn-By-Polygon UIWG was conducted based on the document written by Jim Ramer (12/14/06). Click
here to reference the Warn-By-Polygon write-up. The five points covered in the UIWG were:


Changes to Polygon Encoding

As mentioned in the link above, this is the most important change made to WarnGen in order to support warning by polygon. This change will allow the user to warn bounded by weather, not political boundaries. Discussions centered around the hatched area in the polygon. Noted was the fact that on the boundaries of the CWA, there could be a possible small gap, which may be a restriction of the gelt files. Click here for more information from Jim regarding the county boundary matching. Most importantly, the area that is hatched is what will be described by the encoded polygon, true no matter where the polygon is on the screen. In support of this change to warnGen, no templates are required to be modified. The warnGenWish executable is the only file that reflects the changes for implementing Warn-By-Polygon.

Prohibit Expanding the Warned Area

When following up a warning, the hatched area cannot be expanded. However, the hatched area may be made smaller to reflect a change in the weather event. If the weather event has changed drastically, threatening new counties, another warning will be to be issued. Theses expanded changes cannot be added to the existing warning. Discussions centered around  the context sensitive Redo Box. Perhaps separate buttons  for separate functions should be added to warnGen to reflect specific functions. Should these be prototyped?  Should the polygon 'snap-back' if the forecaster tries to expand the area? Should the polygon snap-back to it's original configuration of last drawn? This issue of redrawing the polygon will be a training issue. Suggested that a dialog box pop-up to tell the use that the resized polygon has no effect?

Shannon White commented that during PIT, forecasters had this feedback regarding Warn-By-Polygon.

Encode the Location and Motion of the Weather Event

Prior to OB8.1, the only information in warnings about the location and motion of the weather event being warned for was in the plain language of the warning. In OB8.1, the scratch products will still contain the plain language description of the location and motion of the weather event. In addition, a line near the bottom of warning will delineating the direction of motion and the storm speed in knots. Currently, this line is tagged with the label STORM. Discussions centered on the what the tag should say. Should it be one line with a label such as LOC-MOTION? Should this information be expanded to two lines, one for the motion and one for the location? John Ferree volunteered to put together several examples and send it out to the group as well as the emergency community to come to agreement on how this should look. Here is the email that John put forth with the examples. The following folks have responded thus far to John's suggestions. Click on their name for their response (I've tried to keep these responses in chronologic order):

Joe Wakefield
Greg Stumpf
Craig Schmidt
Greg Noonan
Bill Ward
Mike Masig
Greg Stumpf - Response Two
John Ferree
Tom Filiaggi
Greg Noonan - Response Two
Tom Filiaggi - Response Two
Jim Ramer
Mike Masig - Response Two
Mike Masig - Response Three
Herbert White
Jim Ramer - Response Two
Greg Stumpf - Response Two
Jim Ramer - Response Three

Always Auto-Update for New Warning

Refer to Jim write-up for a description of the change made for OB8.1. Briefly, if a product is loaded and overlayed with a warning display, the latest frame for the overlay product will be recreated with the time of the new product that drove the notification. The frame times of the underlay product will not be affected by this. If the time matching detects that the new product being notified is more than two cycles newer  than the latest underlay product, then this type of auto update will be ceases so that the time mismatch between the overlay and underlay products in the latest frame does not grow unreasonably large.

Shannon commented that when testing this feature, the coding was sufficient and forecasters were pleased with this feature.

Show Separate Fixed Color Overlays for Each Warning Type

Multiload products have been created to display the following product groupings:

Local & Regional SVR, TOR and EWW Warnings
Local & Regional Flash Flood and Flood Warnings and Flood Advisories

The colors assigned to the products is constant. The user has the option of change the color or unload a product of the multiload has he wishes. One suggestion from the group was to create a product which has all the warnings in one product.

Repectively Submitted,
Susan M. Williams
4 January 2007