Keywords: SVG, weather, Web Service, GIS, MITRE, ESRI, JWIS, JMBL
Biography
Sam Epstein graduated from Georgia Institute of Technology in 2003 with a major in Computer Science. He is a Software Engineer at The MITRE Corporation. He is a member of the AF Weather Program. He is currently working with Geographic Information Systems and Scalable Vector Graphics.
Biography
Daniel J. Hebert is currently the Chief Engineer for the AF Weather Program at the MITRE Corporation. He holds a Masters degree in Computer Science from Florida State University. With over 25 years of experience in the field, he has contributed to a broad range of programs including the Space Shuttle, Joint Stars, and the IRS Modernization. Primary areas of expertise include database technologies, operating systems, software architectures, and geographic information systems. He is also an adjunct professor at Boston University teaching courses in databases, data warehousing/mining, XML Technologies, and geographic information systems.
Biography
John M. Klingler is the deputy Chief Engineer and Architecture Lead for the AF Weather Program at the MITRE Corporation. He earned his Master degree in Electrical Engineering from Northeastern University. His experience has been in the planning, design, and implementation of telecommunication systems, network management and control, air operations command and control, intelligence sharing, and, most recently, large-scale information technology systems. His current interests are in the application of enterprise engineering, complex systems engineering, and service-oriented architectures (SOA) to the unique problems of US Department of Defense systems.
1. Introduction
2. High Level Overview
3. Weather Visualization
3.1 Wind Barb Representation
3.2 Contour Map
3.2.1 Classification
3.2.2 Coloration
3.2.3 Blob Detection
3.2.4 Boundary Tracing and Polygon Creation
3.3 Spatial Projection
3.4 Background Graphics
3.5 Final Aggregation
4. PDA Client
5. Conclusion
Bibliography
As the US Air Force transitions to a network-centric enterprise architecture, the Air Force Weather Program will transform from a collection of stovepipe systems to a constellation of services. Each service will conform to an open interface and perform a modularized task. This loosely coupled service oriented architecture will facilitate a larger number of diverse clients of weather information in an enterprise system.
The US Air Force Weather mission is to provide accurate, relevant and timely air and space weather information to many users. Weather products are generally in three formats: imagery, text, and binary files. Weather forecast model results are stored in the binary format. They represent the predictive values of specific weather parameters (such as temperature or pressure) at a particular height and rectangular latitude\longitude bounds. The models are stored in a binary general-purpose, bit-oriented data exchange format, known as GRIB (short for Gridded Binary). This standard is maintained by the World Meteorological Organization [WILKERSON].
Our mission at MITRE is to apply enterprise level solutions to facilitate effective weather product tailoring and dissemination solutions. Recipients of weather information, such as mission planners, want meteorological information in a readable and standardized format, with esoteric domain information minimized. By using an SVG Weather Web Services, the responsibility of visualizing model information can be alleviated from weather recipients. This encourages a loosely coupled configuration, where clients can request weather information from very thin clients.
WeatherSVG is an SVG Web Service which performs product tailoring of meteorological data. WeatherSVG processes inputted forecast model data and responds with an SVG Visualization of the result. The service follows the request and response model. The SVG is embedded into the XML response. The XML request to WeatherSVG specifies the user choices in the layout of the end product, and a link to the GRIB file to be downloaded. The XML response contains an SVG visualization of the model data, along with associated metadata.
WeatherSVG does not produce forecast models. It requires third party service to create the grib files and provide a link to them. The Joint Weather Impact System (JWIS) is used in the current configuration for weather dissemination. JWIS is a weather dissemination tool owned by the Air Force Weather Agency, produced by the Raytheon Corporation. JWIS is a web service. Its XML schema interface is the Joint Metoc Broker Language, a U.S. Department of Defense standard for web weather services. In the XML request, the user requests a spatial bound, a time frame, and the interested weather parameters. If JWIS contains the request data in its database, it produces a GRIB forecast model matching the user's requests. JWIS responds with an http link to the processed grib files.
By using JWIS in conjunction with WeatherSVG, a client can request and receive a dynamically generated weather visualization. The client first requests meteorological information from JWIS. JWIS responds with a link to the newly created file. The client sends this link to WeatherSVG, which itself downloads and processes the information. WeatherSVG responds with an SVG illustration of the weather.
Figure 1. The client requests JWIS and WeatherSVG respectively.
WeatherSVG translates GRIB model data into SVG visualizations. A GRIB model file contains one or more records. Each record contains a 2D array of binary data describing a weather parameter (such as temperature or visibility) over a particular region. The raw data is set at a particular height, processing time and forecast offset. WeatherSVG creates an SVG visualization for each raster record in the inputted GRIB file.
There are several methods to converting raster data to vector data. One approach is to iterate through every datapoint in the raster array and draw a corresponding rectangle with a color representing the value [Tsoulos]. This method produces a highly accurate replication of the original data, but the output size is very high. WeatherSVG conversion algorithm leverages off of standardized weather symbology and the strong support for polygons to produce a visually relevant, yet compact output. WeatherSVG has two approaches to representing weather parameters. For wind information, WeatherSVG produces a series of wind barbs. For the other weather parameters (e.g. temperature, pressure) WeatherSVG produces a contour map, in which colored polygons each represent a local region of similar data. These outputs are projected using a lambert conformal projection into device coordinates. A background is clipped and projected behind the weather visualization.
Figure 2. A wind barb points into the direction of the wind source.
Wind Barbs are used to represent the speed and direction of wind. The wind barb points in the direction in which the wind came from. The barbs along the side describe the wind speed in knots.
Figure 3. The different speeds of the wind barb.
To create Wind Barbs, WeatherSVG needs the direction and speed of the wind at any given point. This information is encoded into two different weather parameters: WindVComponent and WindUComponent which specify the longitudinal and latitudual magnitude of the winds. WeatherSVG has two representational approaches to Wind Barbs: with symbols and hrefs, or with absolute geometry.
In the symbol approach, every distinct wind speed is stored using the <symbol> element in the definition section of the SVG. The geometry consists of <line> <polygon> and <rect> elements. The symbols are displayed utilizing the <use> tag. The <use> element contains an href to the matching symbol. The <use> tag has translate and rotate transforms to position the wind barb with the correct latitude longitude point and wind direction. The symbol based approach reduces overall SVG size because wind barbs can reference the same symbol. However the display of symbol based wind barbs is computationally expensive and can be slow for PDA based viewing.
The standard approach to wind barb visualization involves directly drawing the wind barbs using absolute coordinates. Since each wind barb contains separate geometry the standard approach to rendering wind barbs produces a much larger output. The standard approach is computationally cheaper to render per wind barb than the symbol based approach. For PDA viewing of smaller geospatial regions, standard based approach is more desirable.
Figure 4. An example SVG wind barb output.
All other weather parameters are displayed in a contour map with polygons. The raw data is combined into a discrete number of groups, each to be represented by a particular color. Adjacent datapoints in the same group are drawn as a single polygon. This algorithm is composed of the following steps:
The dataset of the inputted raster is sorted into discrete groups. The number of groups is roughly analogous to the complexity of the output. The user determines the number of groups. Each group represent a particular interval on the dataset histogram. Each group also has a target value, usually at the center of the interval, which will be used for coloration. Any datapoint which falls within a particular group's interval will become its member. The simplest way to determine the intervals is to divide the histogram range into equal values. WeatherSVG uses quantile classification, in which intervals are arranged to produce the same number of datapoint members.
Each group is assigned a color using a color ramp. The color ramp is formed from a start rgb color and an end rgb color. The start color is associated with the lowest value in the histogram and the end color is associated with the highest color in the histogram. The colors in the groups are determined by the group's perspective target value. The resulting color is a linear interpolation between the start and end color based off the relative distances of the target value to the lowest and highest values.
From the 2D, the blob detection algorithm outputs a set of blobs. A blob is a set of adjacent points belonging to the same group. Each blob is given the color from the group which the datapoints belong to. WeatherSVG is a standard region merging algorithm [Zucker] .
In this phase, the set of blobs are converted into a set of polygons. WeatherSVG uses a novel algorithm which draws the boundaries of the blobs. The boundaries are drawn midway between the edge points. The boundaries are drawn with vertical, horizontal or diagonal lines. The coordinates of the outputted polygons will still be relative to the row and column of the 2D data array. The vectorization proceeds through the creation of a "midpoint boundary" around the blob. This algorithm consists of following steps.
Figure 5. Each color represent a distinct group.
Figure 6. Every horizontal and vertical midpoint between the blobs is found.
Figure 7. The corner midpoints are added.
Figure 8. The created midpoints do not extend past position of the four corner points.
Figure 9. The diagonal connections are created through a search at each midpoint.
Figure 10. The final output for all the blobs.
The outputted geometry of the wind barb and polygon creation algorithms is in array coordinate space. The points are projected from array coordinates to Lat, Lon coordinates to SVG coordinates. To convert between these systems, the following steps are taken.
At the users request, WeatherSVG provides a background underneath the polygon's or wind barbs. The background information is taken from ESRI Shape files, and processed using ArcGIS 9.0 Shape libraries. These files contain polygons in the latitude, longitude coordinate system.
The background polygons are clipped against the lat, lon output bounds. The background is clipped using an algorithm analogous to the Liang-Barsky Polygon Algorithm [WILKERSON] In this approach, each line of a polygon to be clipped is checked against the clipping boundary. Lines inside the boundary are trivially accepted. Lines outside the boundary, are trivially rejected. Lines that intersect the boundary are reduced to the portion which lies on its interior. If a line starts, ends, or crosses a corner region, the corner point is included. Any neighboring duplicate points are deleted. The latitude and longitude points of the clipped background are converted into SVG coordinates using the algorithm mentioned above.
Figure 11. The continental United States is clipped against a smaller window.
The wind barbs or polygonal information is overlayed on the background. The polygons are overlayed with a degree of transparency, or cohesive viewing. At the user request, a legend can be inserted at the bottom of the picture. The legend displays the temporal and spatial information about the picture, and the value associated with each color.
Figure 12. Wind and contour output over a georefenced map.
A PDA client to WeatherSVG was created, PocketSVG, a third party software created by CSIRO, was used to view the SVG files. PocketSVG supports the Tiny specification version 1.1 [ANDERSSON]. WindPDA allows the user to select only wind components. Using three separate forms, the Lat/Lon Bounds, the Time range, and the desired height level is picked.
An additional options form lets the user set advanced options (such as URLs). By default, the client requests for meta information, to enable scripting. This meta information is a transparent rectangle above every wind barb. The rectangles contain, as attributes, the latitude longitude, direction and speed of the wind barb. Weather requests are sent to JWIS and then WeatherSVG. The client views the returned SVG in the PocketPC Internet Explorer using PocketSVG as a plugin. Information about the SVG is displayed on the page.
Figure 13. The SVG response of WeatherSVG is displayed in a PDA.
Using JSCRIPT scripting , the user can click on individual wind barbs to retrieve the latitude, longitude, direction (degrees) and speed (knots).
Figure 14. By clicking on a particular point, the barb's position and wind direction is displayed.
Using colored polygons to represent weather produces a smaller output than the direct pixel to SVG approach. This process, however is more computationally intensive. The four step approach to polygon creation: Classification, Coloration, Blob Detection, and Polygon creation followed by spatial projection provides an efficient and flexible framework for the convertion of georaster data. In this framework, different individual processing algorithms can be used.
Scalable Vector Graphics posed no constraints in visualizing weather in a geographic context. The wind barb shows how to display and reuse weather symbology. By using <symbol> tags, the entire weather symbology can be displayed. A greater task would involve the creation of more weather SVG symbols, encompassing the entire Defense Information Systems Agency symbol set [METOC].
The ease of use for the ESRI spatial projection libraries indicates the general compatibility of SVG and geographic representations. The SVG coordinate space can be seen as analogous to the window rendering space, enabling quick adaptability with geographic systems which render into device coordinates.
Visualization processes which are rather complicated yet produce relatively small output, such as WeatherSVG, are the best candidates for modularization to a SVG Web Service. SVG Web Services offers several major advantages to a network centric enterprise. This concept of a visualization service is gaining recognition in the Enterprise System community. This prototype indicates the potential of a suite of SVG services which provide a combination of visualization services to constrained clients, such as tablet PCs or PDAs.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.