Unlike so many other new warngen features in the past, there are no turnkeys available for activating the warning by polygon features; they are unconditionally invoked when the 8.1 release is installed. Warning by polygon has been designed such that no template changes are required to invoke its features. In order to have some control over when certain of these features become active, it has been proposed that the 7.2 version of the warnGenWish executable be left in place upon initial installation of the 8.1 release. This would mean that when inially installed, the 8.1 updates for the warning display would be available but not the changes in warnGen behavior. The 8.1 warnGenWish executable would then be installed at a later coordinated date in order to activate warning by polygon. This would mean that, unlike most other turnkeys, warning by polygon would be activated without modifying any static data structures. The advantage here is that there will be no possiblity of unexpected interactions with the static data structures used to support the yet to be activated turnkey for VTEC in hydrologic warnings. There are a few other minor capabilities that were discussed as being part of the warning by polygon effort that are nonetheless already part of OB7.2. These were brought in to support the conversion from using the SAW to support watch display to using the WOU. These will not be discussed here.- Encode the polygon in the scratch product such that it describes the hatched area on the screen. - Prohibit expanding the area warned for follow-up products. - Encode the location and motion of the weather event in the scratch product. - Always auto-update the warning display when a new warning is issued. - Show separate fixed color overlays for each warning type.
This is by far the most important change to support warning by polygon. In the screen shot that follows, please notice that the hatched area is different than the area of the polygon:
There are three ways this happens when one initially issues a warning.
First, users are allowed to set adaptable thresholds in the template
that automatically remove counties from the warning if only a small
part of the county is in the box. Second, a user can toggle a county
on or off using the third button over the county in question. Finally
(as is the case in this example), if the polygon extends past the
county warning area boundary the hatched area will be truncated to the
CWA boundary. The hatched area will also be truncated to land areas
for non-maritime products and to water areas for maritime products,
but this is really just a specific instance of the CWA truncation
case.
Upon using OB8.1 warnGen, one will notice that the polygon on the
screen will not necessarily immediately reconfigure to match the
hatched area. There is a reason for this. Suppose one is in the
process of manipulating the polygon to account for the weather
near a coastline or some other complex feature. It could make
it difficult to continue to adjust for the weather if suddenly
there were 20 additional vertices forced into the polygon. If one
toggles some unrelated county on and off with the third botton to
activate the polygon redo feature, one can always then select
Redo Box to see what the encoded polygon will look like.
Remember, THE AREA THAT IS HATCHED IS WHAT WILL BE DESCRIBED BY THE
ENCODED POLYGON. This will be true no matter where the polygon
is on the screen. The logic that invokes this feature is will not
require any template changes, just the OB8.1 version of the warnGenWish
executable.
Before OB8.1, the only restriction to the area definition used in creating a follow up product (SVS, for example) was that no new counties be included and that there be at least some overlap between the previously warned area and the newly warned area. The screen shot that follows shows what happens in OB8.1 if one attempts to expand the area warned within an existing county.
Notice that there is no prohibition on expanding the polygon,
but the hatched area will not expand beyond its area in the
antecedant product. The area hatched will respond to making
the area of the polygon smaller. In any event, it will still
be true that no matter where the polygon is on the screen,
the area that is hatched will be described in the scratch product
by the encoded polygon. We use an SVS in this example to demonstrate,
but this behavior will occur all other followups (FFS, FLS, MWS) as
well. Again, no template changes are required
to invoke this feature, just the OB8.1 warnGenWish.
Before 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. This is a very imprecise definition; this restricted the bearing description to eight compass directions, and the speed description to the rounding used to make the language cleaner. Furthermore, the weather location was also described in the same limited way in terms of a distance and bearing from some town or city. What follows is a fragment of the text from an OB8.1 warnGen scratch product.
* AT 425 PM MST...NATIONAL WEATHER SERVICE DOPPLER RADAR INDICATED A SEVERE THUNDERSTORM. THIS STORM WAS LOCATED 12 MILES SOUTHWEST OF AKRON...AND MOVING NORTHEAST AT 20 MPH. * THE SEVERE THUNDERSTORM WILL BE NEAR... AKRON AND 8 MILES WEST OF PLATNER BY 500 PM MST LAT...LON 4031 10316 4011 10303 3998 10346 4014 10356 STORM 245 18 4010 10340 $$The scratch products will still contain the plain language description of the location and motion of the weather event just as before. In addition, notice the line near the bottom that begins with STORM. This line encodes the direction of motion of the weather event in meteorological degrees from, its speed in knots, and its latitude and longitude at the issue time of the product. If the weather event in question is a line of storms, then multiple latitude and longitude points will be encoded (but still only one motion). Furthermore, this more accurate description of the weather event motion is utilized to make the followup capability work better. What follows is a screen shot of an OB8.1 warngen in the process of generating an SVS scratch product.
This is the state immediately after selecting the CON option. Notice
that the motion depicted is not along one of the eight primary compass
directions, as it would be without the encoded motion being present.
This will make it possible to follow a storm with a constant
motion through its entire life cycle without making adjustments
to the tracking icon.
This behavior is also invoked without template changes. In OB8.1, the
<COORDS> substitution now encodes both the polygon and the
weather event. If one truly wants to encode only the polygon or
only the weather event, the new substitutions <POLYGON> and
<STORM> have been made available.
In order to avoid unnecessary format checking false alarms before
warning by polygon is activated, the OB8.1 format checking will not
try to verify the existence of the STORM line. This would be fairly
simple to add in a future release.
The warning displays in the D-2D are a special kind of product from the standpoint of time matching. When a warning display is overlaid on an existing product, its frames acquire the times of whatever is underlaid, rather than the times associated with the warning products themselves. Each frame then displays any warnings of the appropriate type valid at the time of the frame. This design has a disadvantage for this case...warnings issued after the time of the last frame of the underlaid data will not auto-update until the next frame of the underlaid data updates.
A small modification has been made to the auto update logic in OB8.1 to deal with this. The modifications do not apply to warnings specifically; they apply to any product which acquires its frame times from the underlaid product. If an overlay product of this type is notified with a time later than the latest underlay frame, 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 cease so that the time mismatch between the overlay and underlay products in the latest frame does not grow unreasonably large. All the logic that makes this feature work is within the IGC_Process executable; no localization or reconfiguration is needed.Up until now, several different product types have been combined into single warning displays. Tornado (TOR) and severe thunderstorm (SVR) warnings have been grouped together, and flash flood (FFW) and flood (FLW) warnings have been grouped together along with flood advisories (FLS). Special marine warnings (SMW) have always had their own separate product.
From the user interface perspective this grouping has been maintained; in fact the set of menu selections for displaying warnings has not been changed at all. What has changed is that the product groups are now configured as multi-loads, like families. With a single click multiple fixed color overlays are loaded, with each overlay corresponding to a product type. The grouping has not changed except that the new extreme wind warning (EWW) has been added to the group with SVR and TOR. Like all multi-loads, if there are certain products types one is not interested in, one can always just toggle off those overlays. The following screen shots show sample displays of the severe weather group and the flood group.
Notice that the colors are not the standard overlay colors; the tables
entries that define these products now include a product specific
default color. The marine warnings display (not shown) is now fixed
with Cyan. Once displayed, this overlay color can of course be
changed with a third button pop-up on the legend.
One potential disadvantage of this new configuration would be for
the case of loading these new multi-loads into an empty display.
In the old configuration, a frame would be created for each
available product of any type. For this new configuration,
frames in this case will only be created for the first overlay.
Because products of this type always create an artificial frame
for the current time, one will still get complete information
about all warnings valid at the current time. However, older
products from the non-primary overlays will often be undisplayable.
One work around is to use a third button pop-up to unload the
primary overlay, creating a set of frame times based on the
next overlay. Another workaround would be to change the
configuration of the multi-loads such that the first overlay
would be the legacy product, albiet toggled off by default.
All the changes needed to implement this are table changes; no
code changes where necessary. The legacy displays remain in the
system to support old procedure bundles, but are no longer available
to load from the menu. When the new tables are in place,
one needs to run the -tables and -text localization tasks to
implement the change.
Here is the set of files commited to CM to support warning by polygon in OB8.1, broken down by subtask.
Always encode polygon as hatch area, and prohibit expanding an SVS:D-2D/src/extensions/warnGen/WarnGen.C D-2D/src/extensions/warnGen/WarnGen.H D-2D/src/geoTables/GeoEntityLookupTable.C D-2D/src/geoTables/GeoEntityLookupTable.HEncode location and motion of weather:
D-2D/src/extensions/foundation/TextTemplate.C D-2D/src/localization/documentation/TextTemplate.html D-2D/src/staticPlotData/LocalWarningInfo.CAuto update improvements:
D-2D/src/dataMgmt/DepictableServer.C D-2D/src/igc/AutoUpdater.C D-2D/src/igc/TimeMatchFunctions.CSeparate overlays for warning product types:
D-2D/src/dataMgmt/multiLoadInfo.txt D-2D/src/localization/nationalData/productButtonInfo.txt D-2D/src/localization/nationalData/textDataKeys.template D-2D/src/localization/nationalData/textDepictKeys.templateThe executables that are functionally affected by these changes are warnGenWish, IGC_Process, and localWarningInfoTest. Implementing this capability requires these executables, updating the four previously listed table files, and running the -tables and -text localization tasks.