WeatherSVG

A Dynamic SVG Web Service

Keywords: SVG, weather, Web Service, GIS, MITRE, ESRI, JWIS, JMBL

Mr Samuel Epstein
Software Systems Engineer
The MITRE Corporation
202 Burlington Rd.
Bedford
Massachusetts
USA
sublime@mitre.org

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.

Mr Daniel Hebert
Principle Information Systems Engineer
The MITRE Corporation
202 Burlington Rd.
Bedford
Massachusetts
USA
dhebert@mitre.org

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.

Mr John Klingler
Lead Multi-Discipline Systems Engineer
The MITRE Corporation
202 Burlington Rd.
Bedford
Massachusetts
USA
jmkling@mitre.org

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.


Table of Contents


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

1. Introduction

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.

2. High Level Overview

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.

Layout.bmp

Figure 1. The client requests JWIS and WeatherSVG respectively.

3. Weather Visualization

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.

3.1 Wind Barb Representation

WindBarb.bmp

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.

WindTypes.bmp

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.

WindResult.bmp

Figure 4. An example SVG wind barb output.

3.2 Contour Map

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:

  1. Classification
  2. Coloration
  3. Blob Detection
  4. Polygon Creation

3.2.1 Classification

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.

3.2.2 Coloration

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.

3.2.3 Blob Detection

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] .

3.2.4 Boundary Tracing and Polygon Creation

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.

  1. The vectorizer receives input from a set of blobs.
    Poly1.bmp

    Figure 5. Each color represent a distinct group.

  2. The vectorizer iterates through every edge-point in the blob. An edge-point in a given blob is a point which has a neighboring point not of the same blob. A midpoint is created for each boundary the edge-point has. The midpoint retains information about its parent edge-point. The midpoint can be to the top, bottom, left or right of its parent edge-point.
    Poly2.bmp

    Figure 6. Every horizontal and vertical midpoint between the blobs is found.

  3. Corner midpoints are added to a midpoint set. Corner midpoints are to the upper left, upper right, lower right, and lower left of their parent nodes. Corner midpoints are automatically connected to other midpoints of the same parent edge-point. There are two different cases when a corner-midpoint needs to be created:
    1. If the edge-point and its neighbor belong to the same blob, but its diagonal neighbor does not.
    2. The edge-point's two neighbors belong to a different blob, but the two neighbors and the diagonal neighbor do not all belong to the same blob.
    Poly3.bmp

    Figure 7. The corner midpoints are added.

  4. The vertical and horizontal connections of the polygon have been formed. The diagonal connections need to be discovered. For each unconnected midpoint, the vectorizer searches counterclockwise for another unconnected process. The search starts at the midpoints parent, to ensure proper connections. The search moves onto the newly found midpoints. Midpoints that are already connected are skipped. The search stops when the first midpoint is happened upon twice. At this junction, a complete ring of midpoints is found. A blob may have multiple rings, owing to polygons which have holes in them. The search continues to produce rings until there are no more unconnected midpoints left.
    Poly4.bmp

    Figure 8. The created midpoints do not extend past position of the four corner points.

  5. Every midpoint in a ring that is not at a corner is removed, and its two connections are merged into one. The polygon is then created from a !path! element. Each ring starts with an M (moveto) point. Subsequent points in the ring are specified with an L (line to). Each ring ends with a Z (closepath). The path is given a fill of the color selected for the group during the coloration phase. This process is completed for every blob.
    Poly5.bmp

    Figure 9. The diagonal connections are created through a search at each midpoint.

  6. The result is a set of colored polygons consisting of vertical, horizontal, and diagonal lines.
    Poly6.bmp

    Figure 10. The final output for all the blobs.

3.3 Spatial Projection

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.

  1. Creation of array coordinate Geometry. The polygon and wind barb algorithm outputs geometry in the array coordinate system. The points in these outputs are in the form (row, column), however they are not restricted to integer values.
  2. Conversion to latitude, longitude coordinates. The bounds of the 2D array is known. The rectangular lat, lon bounds of the model file is known (minLat, maxLat) (minLon, maxLon). The arrays are assumed to be equally spaced. Under this assumption the array coordinates are converting to latitude and longitude points using linear interpolation.
  3. Conversion to SVG Coordinates. The latitude and longitude points are projected onto a 2D plane: the svg viewbox. ArcGIS 9.0 spatial libraries from ESRI were used for this projection. ESRI is a global industry leader in geographic information software systems. The libraries used classes which traditionally provides support for translating ESRI's geographic files onto windows. A DisplayTansformation object was used. This object is given a spatial reference, which describes the rectangular latitude and longitudinal bounds. The DisplayTransformation object was given output device coordinates matching the SVG viewbox's coordinates. With this information, the DisplayTransformation accurately projects latitude and longitude points into device coordinates.

3.4 Background Graphics

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.

PBack.bmp

Figure 11. The continental United States is clipped against a smaller window.

3.5 Final Aggregation

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.

windtemp.bmp

Figure 12. Wind and contour output over a georefenced map.

4. PDA Client

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.

PDAWind.bmp

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).

PDAInteractive.bmp

Figure 14. By clicking on a particular point, the barb's position and wind direction is displayed.

5. Conclusion

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.

Bibliography

[Liang]
LIANG Liang, Y-D., and Barsky, B., "An Analysis and Algorithm for Polygon Clipping," CACM, 26(11), November 1983, 868-877, and Corrigendum, CACM, 27(2), Feburary 19884, 151.
[WILKERSON]
WILKERSON Wilkerson, Walter D. U.S. DEPARTMENT OF DEFENSE. WMO FORMAT FOR THE STORAGE OF WEATHER PRODUCT INFORMATION AND THE EXCHANGE OF WEATHER PRODUCT MESSAGES IN GRIDDED BINARY FORM AS USED BY AFWA OPERATIONS. 25 Mar. 2003. 1 Oct. 2004<https://wwwmil.offutt.af.mil/afwa/xord/.>
[ANDERSSON]
ANDERSSON Mobile SVG Profiles: SVG Tiny and SVG Basic, O. Andersson, editor, W3C Recommendation 14 January 2003. <http://www.w3.org/TR/SVGMobile/>
[ZUCKER]
ZUCKER Zucker, Steven. Region Growing: Childhood and AdolescenceIn Computer Graphics and Image Processing 5, 382-399 (1976) .
[METOC]
METOC MIL-STD 2525B Appendix C Meteorological And Oceanographic (METOC) 30 Jan. 1999. Defense Information Systems Agency. 3 May 2005 <http://symbology.disa.mil/symbol/mil-std/appendixc/appendixc.pdf> Smbology.
[Tsoulos ]
Tsoulos Tsoulos, Lysandros. Converting raster images to XML and SVG. 10 Sep. 2004. SVG Open 2004. 6 May. 2005

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.