For the set of hazards that Hazard Services will support for IOC, only one, convective flash flood warnings, can benefit from having the ability to track a weather feature.  Furthermore,

the fraction of flash flood events where the flooding follows the track of a thunderstorm is very

small; the vast majority of them are confined to a drainage basin and do not follow the movement of the storm(s) that generated them.  As such, our initial implementation of storm tracking in hazard services will be limited.  It will only allow the tracking of features represented as a single point, and those features will be tracked with the assumption that they move with a completely constant speed and direction. Future implementations of the storm tracking will also account for features represented by a polyline or polygon, and will allow the feature being tracked to change speed, direction, and even shape over time, but these capabilities will all be introduced post-IOC.

Storm tracking in the PV2 version of Hazard Services is supported by two separate tools that run in the new recommender framework. The first, StormTrackTool.py, is used to initialize the motion of the weather event based on a user selected location and an assumed default motion.  The second, ModifyStormTrackTool.py is used to manage all subsequent updates

to the track.

Before the execute() method of StormTrackTool.py ever runs, the tool asks the recommender framework to present the user with a movable point labeled with ‘Drag Me To Storm’.  This is specified by what is returned by the defineSpatialInfo() method, as follows:

def defineSpatialInfo(self):

   resultDict = {"outputType":"spatialInfo",

                 "label":"Drag Me To Storm", "returnType":"Point"}

   return resultDict

The user then drags this point from its initial location in the center of the current frame to the approximate location of the weather feature to be tracked.  When let go, the exectute() method of StormTrackTool.py then runs.  Depending on which setting is in place, a pending event of either a flash flood warning or a tornado warning is created. The user can later change the selected event type using the Hazard Information Dialog. For now, the initial duration of this event will be default of the setting, limited to a maximum of three hours.

In the current version of StormTrackTool.py, the logic for choosing the initial motion of the feature to be tracked is very simplistic.  The motion is always from the southwest, and is always at 20 knots for an event duration of 30 minutes; it will be slower for longer event durations.

For both StormTrackTool.py and ModifyStormTrackTool.py, the execute() logic is broken into two main parts.  All the logic that interacts with Java backed data structures within the recommender framework is implemented directly in the execute() method. All the logic that is meaningful without the context of the recommender framework is in a method called updateEventAttributes().  Standalone python units tests of the storm tracking tools only call updateEventAttributes(). When the storm tracking tools run within the recommender framework, the execute() method is called by the framework, which calls updateEventAttributes() internally.  The primary job of the logic in execute() is to construct or modify the HazardEvent, which is directly backed by a Java object and contains everything associated with the hazard that is directly entered into the hazard database.  It is the job of updateEventAttributes() to assign all the arbitrary associated attributes that go along with the HazardEvent, many of which only have meaning in the context of a hazard based on a moving weather event.  There are several data items that go into the formal HazardEvent for which the values are determined within updateEventAttributes(); these are placed in a temporary entry in the attributes with a key of “forJavaObj”.  The “forJavaObj” entry is deleted from the arbitrary attributes before they are given to the HazardEvent.

Within the updateEventAttributes() method of StormTrackTool.py, one of the most important assignments to the arbitrary attributes is as follows:

resultDict["modifyCallbackToolName"] = "ModifyStormTrackTool"

This is what tells the recommender framework that after StormTrackTool.py runs, all further interaction with the Hazard Services geographic display should result in executing ModifyStormTrackTool.py in the recommender framework.

It is completely plausible that a focal point might create a customized version of

StormTrackTool.py.  The purpose of this would be to change either the initial event type, the initial feature motion, or the initial event duration.   These determinations have all be separated out into their own methods do that it is obvious where to make these customizations. The default algorithms for all of these determinations will be updated in future Hazard Services releases; at a minimum the motion vector applied to 8 bit SRM will be used for the initial motion, as in WarnGen.  A customized version of StormTrackTool.py will still be able to use the existing version of ModifyStormTrackTool.py to update the track.

While making customized versions of ModifyStormTrackTool.py will not be prohibited, it is not expected that this will have much utility.  The default version of ModifyStormTrackTool.py is going to undergo extremely heavy modification following IOC.  This eventually will include being able to track features whose shape is determined by a polyline or polygon, the ability for the motion and shape to change over time, and an associated modeless dialog to allow the user to choose which of these higher level tracking features will be applied.  If a focal point spends a large amount of time making a customized version of ModifyStormTrackTool.py,

it will not be possible to guarantee that the customized version will remain compatible with the future changes in the recommender framework required to support the new functionality in the default version of the storm tracking.

In an A-II system that has Hazard Services installed, the default code for these recommenders will live in EDEX and be installed in this directory:

/awips2/edex/data/utility/common_static/base/python/events/recommenders/

Making a custom version of StormTrackTool.py would involve copying the default version to /awips2/edex/data/utility/common_static/user/$USER/python/events/recommenders/,

and then modifying its logic.  This explanation of where these files live in the file system is only meant to aid in understanding how customization works.  If one were to actually try to implement a customized version of StormTrackTool.py, this should be done through the localization perspective.