XML.com: An SVG Case Study: Integrated, Dynamic Avalanche Forecasting

An SVG Case Study: Integrated, Dynamic Avalanche Forecasting
Pages: 1, 2

SVG provides a tag to uniquely identify a group of visual elements. Here we use SVG's group ("g") tag to give the elements that define our graphic a name ("id"). The name that defines our graphic will be used by our JavaScript event handler. The next thing we want to point out is SVG's handy transform attribute. First, scale provides a way to scale or resize your object or entire group of graphic objects. The translate attribute lets us move the graphic to a particular location within the coordinate system. Why are we doing this? In AMT we have a rectangular view port within which we display the various graphs of the weather stations. The individual weather station SVG graphics have their own size and coordinate system; we must transform the size and positioning of the graphic so that once it is added to the AMT, it fits inside the rectangular view port. This means that you can use just about any SVG graphic anywhere you want.

<g id="altaGraph" width="6000" height="4500" 
  transform="scale(.104,.0973) translate(2625,1230)">

Then we draw the various graphic primitives such as the outer chart box:

<rect x="0" y="0" width="6000" height="4500"
  fill="#dcdcdc" stroke="black" stroke-width="20"/>

We place a trash can image for disposing or removing a particular chart with the onclick="snowTkMetRemove()" function (this is the really exciting part which we will discuss in step 5 below):

<image xlink:href="./images/trash.gif" x="5700" y="50"
width="300" height="300" style="display:inline"onclick="snowTkMetRemove(evt)"/>

Once the base layer of graphical components are constructed, and we have prepared the data, it is a simple matter of outputing the data like the Temperature line segments (blue line graph):

<polyline fill="none" stroke="red" stroke-width="7"
  points="400,1533.33 431.13,1533.33"/>

There are many other lines, rectangles, and text values which are placed on the chart but are not displayed here. For more information on SVG details refer to SVG Essentials by J. David Eisenberg.

We have automated the chart generation process to follow the data harvesting. There is one additional step for chart creation: compression. The Adobe SVG plug in permits zip compression of the source files. This is useful in our case because the SVG text files are approximately 200 Kilobytes. That's not huge, but when you are trying to get out the door, time is of the essence. By zipping these files with gzip we can gain an order of magnitude reduction in file size. For example, one chart is 199955 Kilobytes before compression and 18247 Kilobytes after. The relative lightweightedness is one of the hidden benefits of SVG over other vector graphics.

Now that the data has been harvested and the charts have been generated, we need to integrate all the charts into a single viewer.

Step 5: Where it all comes together

Each weather station is a separate SVG file and presentation. However, for our purposes we need to integrate each station into a regional Toolkit so that the user can jump from one station to another and see a consistent output of relevant information. In a sense, the Toolkit is a visual information appliance used for displaying external weather data.

For the toolkit interface, you can see that we employ some of the same SVG display options like creating a box, adding an image and a transparent overlay to create a list of "Meteorological Graphs" shown in Figure 3 and in the code sample below:

Figure 3: List of Graphs

<g id="smallWindowTemplate">
<desc> The background Template </desc>

<image xlink:href="./images/avalanche1.jpg" x="35"
  y="120" width="220" height="280"style="display:inline"/>

<rect x="45" y="130" width="200"height="260" 
  fill="yellow" opacity=".6"stroke="none" stroke-width="5"/>

<rect x="35" y="120" width="220"height="280" 
  fill="none" stroke-opacity=".4"stroke="red" 
  stroke-width="3"/>

<text style='font-size:12pt; font-weight:bold; 
  font-family:sans-serif;fill:black; text-anchor:center;' 
  x="60"y="150">Meteorological Graphs</text>

<text style='font-size:12pt; font-weight:bold; 
  font-family:sans-serif;fill:black; text-anchor:center;'
  x="70"y="180">Utah:</text>

</g>

We then add each weather graph choice as a radio button:

<g id="messageWindow">

<text style='font-size:10pt; font-family:sans-serif; 
  fill:black;text-anchor:left;' 
  x="95" y="200">Alta</text>

<circle id="wx1a" cx="85" cy="195" r="5" 
  fill="blue" stroke="black" stroke-width="2" 
  onclick="snowTkMetALTA(evt)" />

</g>

Aside from the basic visual elements, we have included an ECMAScript onclick event. This is where we take advantage of Adobe's SVG plugin server-connection capabilities to load external data sources. In this case, our external data is the station-specific SVG graphs we produced in steps 3 through 4. This functionality is very nice because once we have developed the AMT appliance we no longer have to touch it, even though the data is constantly changing. We simply refer to that external data source, which also means we download only what is requested. Figure 4 shows a specific weather station graph within the complete Toolkit interface.

Figure 4: The Completed Toolkit

This process of loading and unloading external data sources requires three methods: one to retrieve the external SVG file with the getURL method, another to act as a callback method that parses, returns, and inserts the XML into the main SVG document tree, and a final method to destroy or delete the inserted XML when the trash icon is selected (see the snowTkMetRemove method in the above code listing that adds the trash can image). These 3 methods are listed below along with the beginning of the SVG document for the Toolkit interface.

<?xmlversion="1.0"?>

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" 
  "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

<svg width="900" height="900" viewBox="0 0900 900" 
  preserveAspectRatio="xMinYMin" >

<!-- ECMAScript --> 

<script type='text/ecmascript'><![CDATA[

// Method calling the getURL()

function snowTkMetALTA (evt)
{
  var node = evt.target.ownerDocument.getElementById("altaGraph"); 
  node=evt.getTarget;
  var url='./altaGraph.svgz';
  getURL(url,snowTkMetCallbackALTA);
}

function snowTkMetCallbackALTA (document)
{
  fragment=parseXML(document.content,document);
  document.getElementById("messageWindow").appendChild(fragment);
}

function snowTkMetRemoveAlta (evt) 
{
  var node = evt.target.ownerDocument.getElementById("altaGraph");
  node.parentNode.removeChild(node);
}

</script>

There are a couple of items to take note of in the ECMAScript. First, notice that we provide the directory path to our weather station graphic. The method getURL() retrieves it and then appends it on to our AMT in the snowTkMetCallbackALTA function. Second, the getElementById() method is given two different arguments: "messageWindow" and "altaGraph". The "messageWindow" argument is the group id of the location in our AMT where we want to append our weather graph. Now, the group "messageWindow" will have a new element that is actually a group of elements that defines our weather graph. "altaGraph" is the group id of the weather station SVG graphic that we want to add.

This is where giving names to graphic elements is important. The "altaGraph" group contains scale and translate information that allows the graphic to fit inside the view port once it is appended to "messageWindow". Not only is it important for placing or inserting the weather graph, it is also important for specifying what portion of the document to remove. (For more information, see Antoine Quint's article SVG Tips and Tricks: Adobe's SVG Viewer at XML.com.) When we are done with each chart, we simply remove it from the document tree and add a new one-very clean.

Summary

The primary benefits of our approach are the integration of disparate information sources into a single, lightweight display of relevant real-time information. Perl, or course, is great for text processing. SVG along with Adobe's server-connection capability has proven to be a very flexible and lightweight means of information display. We are planning the integration of additional dynamic information like avalanche pictures posted by the public, integration of the Utah Avalanche Center forecast advisory, and a regional map of recent avalanches. By combining all this information in one place, backcountry travelers and avalanche forecasters have been able to quickly assess backcountry conditions and make appropriate, informed decisions. There is no end to the possibilities for creating dynamic, lightweight displays of real-time data: other scientific monitoring devices, traffic monitoring, manufacturing processes, financial data, and so on.

Resources

Leave your comments or questions on this article in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only

Newest First

Non-proprietory SVG is even better!
2003-04-24 12:09:38 Robert McKinnon [Reply]

Because the Avalanche Meteorology Toolkit (AMT) does not strictly adhere to the SVG 1.1 specification[1] I am unable to use it with the Squiggle SVG Browser. Strictly adhering to Web standards[2] reduces the cost and complexity of development while increasing the accessibility and long-term viability of any site published on the Web.

I am a Linux user who views SVG content using the Squiggle SVG Browser that comes with Apache's Batik SVG toolkit.[3]

I have found two reasons why AMT does not work on Squiggle:

1) AMT's SVG does not match the SVG 1.1 specification in a few instances. For example, 'left' and 'center' are not valid values for the text-anchor property. The valid values from the specification are 'start' and 'middle'.[4]

2) AMT makes use of proprietory Adobe SVG Viewer features that are not part of the SVG 1.1 specification. Rather than using Adobe's server-connection capabilities to load external data sources, xlink:href links in the menu could be applied to achieve the same effect. A click on the menu would then request new pages from the server, thus making use of the traditional HTTP GET request to retrieve new data views.

As it stands the AMT looks like a great toolkit, however currently it's a proprietory Adobe SVG Viewer application. With a little work it could be made into an awesome open-standard, cross-platform compatible Web application, by strictly adhering to existing W3C Web standards.

[1] http://www.w3.org/TR/SVG11/
[2] http://www.webstandards.org/about/
[3] http://xml.apache.org/batik/
[4] http://www.w3.org/TR/SVG11/text.html#TextAnchorProperty
- Non-proprietory SVG is even better!
  2003-04-25 14:53:37 Tyler Cruickshank [Reply]
  
  Robert,
  
  Thanks very much for giving our article a read and for providing some good food for thought.
  
  In short, we agree with your comments. SVG is open-source so we ought to stay away from any proprietary features.
  On the other hand, when we originally built the toolkit a year and a half ago, we simply wanted to get it done. Most of our users prefer the easiest method of viewing the SVG, therefore, the Adobe viewer was the easiest solution. Having said that, now that we have the toolkit functioning and are more familiar with dynamic data-driven SVG we should and intend to go back and remove the proprietary features.
  
  Down the road, if we keep our SVG adhering to the W3C standards, we wont have to worry what viewer is being used.
  
  Thanks for reminding us.
  
  -tyler