The cost of transportation is greatly affected by weather. Severe weather can damage transportation networks and carriers costing millions of dollars in repairs. Conversely, delaying or rerouting carriers due to perceived adverse, but inaccurate, weather conditions can also increase transportation costs.
Transportation personnel in charge of operational decisions require timely and accurate dissemination of weather data. Specifically, they need a weather notification system that:
A GIS-based weather advisory notification system can fulfill many of these requirements. In this paper, we discuss how such a system can be implemented using the Union Pacific Railroad as a case study. We describe the system specifications, technology used, and results. We conclude with an analysis of how many of the components used in the Union Pacific Railroad solution can be generalized for other transportation applications.
An Automated Weather Advisory Notification system was deployed at the Union Pacific Railroad dispatch center in the April 2000 by DTN Weather Services.
The main purpose of the Automated Weather Advisory Notification system is to alert the railroad dispatchers of weather conditions that may affect railroad operations. One of the most important features is its ability to filter out extraneous general weather information, and focus on conditions that are actually important to the operation of, in this case, a railroad. Alerts are targeted for specific dispatchers depending on the geographic regions for which they are responsible. This prevents the dispatchers from learning to ignore the weather alerts due to information overload.
The system makes use of DTN Weather Services' extensive access to real-time weather sources, and experience in graphical analysis of geographic data and processing of weather-related data.
The filtering of weather information takes place at the DTN Weather Center in Burnsville, MN, while the dispatchers receiving the weather alerts work in the Union Pacific dispatch office in Omaha. Reliable communication between the two sites is essential.
Union Pacific Railroad required total coverage of their railroad network with guaranteed delivery of critical weather alerts for extremely time-sensitive decision making.
Thresholds for determining if weather conditions should generate an alert message were specified as:
If a weather condition from any of the above sources is expected to impact the Union Pacific track segment network, DTN Weather Services will provide automatic notification of the specific weather alert condition to one of several Union Pacific locations.
Each alert message will contain an event condition type, event start time, event end time, and track segment(s) affected by the weather condition. In addition, a detailed map of the affected tracks and an overview map of the area will be sent with the alert message.
Union Pacific will maintain and supply shapefiles containing the locations and numbers of all track segments. Included in these shapefiles will be the IP address of the individual dispatcher who is currently responsible for the track segment as well as the IP address of the Service Interruption Desk and the Dispatch Corridor Manager desk.
Each step in the notification process is documented in a weekly-archived log file and available to Union Pacific upon request.
The design solution required three main components:
The application is implemented as Avenue scripts, which run within the ArcView execution environment. Avenue scripts can't call COM interfaces directly, but they can call exported functions in C DLLs. In order to make the connection to the Alert Distribution component, the Avenue scripts make calls to DLL-resident wrapper functions to construct an XML text message and to send the message to the Messaging applications.
The following examples document the weather alert messaging process from receipt of satellite weather information to sending an alert message.
The process begins as the Metwork GIS Fileserver receives a weather data file and completes the conversion to a shapefile format ( 1 to 10 seconds ).
Data is read in as a point shapefile. Database fields include direction, speed, intensity (decibels), probability of hail, maximum hail size, liquid content, cloud top height, and presence of a mesocyclone or tornadic signature.
Union Pacific is only concerned that a tornado may blow over a train. Hail and rain do not affect train movement. Therefore, only storms with a Tornadic Vortex Signature (TVS) are selected.
For each storm with a TVS, ArcView builds a storm corridor graphic shape from the storm's location, direction and speed. This storm corridor extends seven minutes into the future (a time frame specified by Union Pacific).
A determination of the intersection between these storm corridor and the the Union Pacific track segments is made. For each intersection, ArcView queries the corresponding IP address for the dispatcher responsible for that segment(s).
A detailed view of the storm corridor and the affected track segments is made. Station names are labeled on the map. A corresponding small scale view of the affected area within the state is also made. Both map views are placed on a layout and then exported as a JPEG file.
ArcView then constructs an XML alert message using C functions encapsulated in a DLL. Another DLL function sends the message to the MSMQ Messaging applications. For all weather Alert Messages, two additional IP addresses are included with the individual dispatch address, that of the Dispatch Corridor Manager and the Service Interruption Desk.
NWS Warnings are converted to a point shapefile. Affected counties are marked by a geographic point. Data fields include issue time, expire time, warning type, state FIPS, county FIPS, and file name of the NWS warning text message.
If a warning is one of the types of interest to the Union Pacific Railroad, coverage areas are constructed by joining the NWS warning shapefile of points with a county polygon shapefile using the FIPS code.
ArcView determines the intersection between the NWS warning coverage and Union Pacific track shapefile. An XML alert message is generated according to the Dispatch desks and Corridor Managers who need to be notified.
These messages are uniquely identified such that the Dispatch desks and Corridor Manager desk can be alerted to the presence of the National Weather Service message, but do not necessarily need to take immediate action. The data included in this type of message is meant to heighten the awareness of Dispatchers to the severity of the weather conditions near Union Pacific tracks. Tornado Warning messages have to be corroborated by WSR-88D NEXRAD data before an actual Weather Alert Message is sent to a Dispatch desk.
Over 1300 weather stations report observations in the US (over 6000 worldwide). Over 30 basic and derived meteorological observations are represented. Metwork GIS converts periodic reports to point shapefiles upon receipt.
Union Pacific wants to stop trains when wind speed (or gusts) exceed 50 mph. They also want to slow train speed when temperatures fall lower than 0 deg F or higher than 105 deg F.
The proximity of an observation to a Union Pacific track also determines priority of a weather observation that exceeds thresholds. A 20 mile buffer is used to notify Corridor Managers, while a 5 mile buffer is used to notify Dispatchers.
A determination of the intersection between these buffers and the shapefile of the Union Pacific tracks is made. For each intersection, ArcView accesses the corresponding IP address for the dispatcher responsible for that segment. For all weather Alert Messages, two additional IP addresses are included with the individual dispatch address, that of the Dispatch Corridor Manager and the Service Interruption Desk.
The idea of weather alert notifications is a logical extension of DTN Weather Services' current services. With this in mind, the design of the system should facilitate the reuse of the components as much as possible. In order to do this, we analyzed which system requirements are likely to be common in future, similar installations, versus requirements that are likely to require customization for specific customers (or types of customers).
Probable areas of commonality:
Probable areas of variation:
To Be Determined: