Interactive Topographic Web-Maps Using SVG

Yvonne Isakowski
Fachbereich Vermessung u. Kartographie
HTW Dresden (FH)

Friedrich-List-Platz 1
01069 Dresden
fax: ++5-351 462 2191

Andreas Neumann
Institute of Cartography
ETH Zurich

ETH Hoenggerberg
8093 Zurich
fax: ++41-1-6331153

Keywords: interactive maps, topographic maps, SVG code optimization


There is a clear demand for web-maps that not only allow to locate places and calculate routes - as it is possible with today's common webmapping services - but also to interact with the map. The paper deals with possible interactive methods that allow to explore topographic maps. To achieve these goals a map-author could either choose expensive GIS-Mapping-Server/Java-Applet/Plugin combinations or use standard web-technology, such as SVG or Macromedia Flash, that are not primarily designed for a use in the domain of mapping or GIS. Along with the paper we present a prototype of an interactive topographic map implemented in SVG/ECMA-Script. This implementation tries to close the gap between high-demands in terms of interactivity on one hand and keeping cartographic quality, using open standards and keeping the code maintainable, on the other hand. While this first prototype already works and proves that the chosen SVG solution is a passable way, we still have to fix bugs, enhance and apply it to larger datasets, kept in spatial databases.

A second part of the paper presents an interactive map-browser for the swiss national 1:25.000 topographic maps. The map-browser was developed by Yvonne Isakowski during her stay at ETH as a trainee. In addition to a small-scale overview-map the viewer features the display of metadata, such as the up-to-dateness of the map-sheet, coordinates of the map corners or administrative units the map covers. Interactive map-browser, such as the one presented, could help the user select a printed map during a visit at an online map-store.

Introduction - Goals of the project

Webmaps in general, and in particular address-matching/routing systems, are extremely popular among webusers. However, while most mapping-systems still lack good cartographic quality - concerning symbology, generalization and labelling -, it gets even worse when examining the level of interactivity that most current webmapping systems offer. Because most current systems are mainly server-based, each interaction still requires contacting database-server, which generate answers/feedback for the requests. This process is quite time-consuming and results in undesirable delays when querying or examining objects. Furthermore, the large-amount of client-server traffic burdens map-servers and bandwidth resulting in the needs for very expensive server/database-cluster and network infrastructure for still being able to meet customers demands. New approaches, using a combination of open webstandards, such as SVG, XML, DOM, ECMA-Script and CSS/XSL, not only allow high (carto-)graphical quality but also a considerably higher amount of interactivity while at the same time saving computing power, license fees and network bandwidth.

The goal of the project was to develop a highly interactive topographic webmap that uses only open standards and may be served and run without paying expensive license fees (in terms of the involved software, both client and server). The resulting work, presented at the conference, is work in progress: some features are already implemented while others are in the queue and should be developed later on the project. The current prototype features map navigation (zooming and panning), display of coordinates and z-values on mouse-move, analytical hillshading with the ability to change the light-vector, switching map-layers, show attribute values, locate places and create cross-sections on demand. A screenshot of the prototype is included below - the interactive SVG-map may be found at the projects webpage. It was not included in the conference proceeding because it is still under development.

Screenshot Prototype Tuerlersee

Figure 1: Screenshot of the prototype "Tuerlersee" (Interactive topographic map) - Link to the project site
© Bundesamt für Landestopographie (JD022306)

Features useful for an interactive topographic webmap

The following table lists a number of features useful for an interactive topographic webmap. It lists wether a feature is already implemented, needs further enhancements, or is only planned so far. Because the prototype is work in progress many features are only partially or not at all implemented. You should contact the projects webpage for an updated version.

Feature Implemented Needs improvement Planned
Navigation, Spatial Reference
Linked Reference Map for Navigation/Panning X - -
Pan at the map-borders/corners - - X
Zooming X X1 -
Show Coordinates on mouse-move X X2 -
Grid Lines X - -
Adaptive Scalebar, automatically generated - - X
Measuring, Locating, Routing
Get Element Length X - -
Get Element Area - - X
Locate Elements X X4 -
Calculation of shortest paths - - x5
Progressive Drawing of the result of a queried route - - x
Attribute-Data Integration
Show linked data on mouse-over X - -
Select Elements by Attribute-Data - - X
Linked DTM, DTM Analysis
Show Elevation Value on Mouse-Over X X2 -
Interactive Hillshading, allows to set light vector X - -
Linked elevation Profile X - -
Calculate Aspect - - X
Calculate Slope - - X
Personal spatial bookmarks - - X3
Change symbolization/colors - - X3
Include personal symbols - - X3
Upload GPS waypoints - - X3

1Currently only fixed zoom-levels, free zoom planned

2Currently has problems on Internet-Explorer/Windows in maximized window

3Requires user profiles and a linked database

4Currently only predefined objects - no flexible search mechanism

5Might be implemented, more complex algorithms ...

Target platforms: OS, Browser and SVG-Viewer

The prototype had been partially developed on Linux and Windows systems with both Mozilla and Internet-Explorer as a Webbrowser. Unfortunately the Adobe-SVG-Viewer for Linux/Mozilla is still in beta-stage and does not generate useful ECMA-script error-messages. The main reason for this drawback are unfrozen or insufficient plugin API's of the Mozilla browser. This circumstance forces us to use mainly the Windows-version and deploy on Linux, Mac, Solaris and Windows. The prototype works on all Browsers supported by the Adobe SVG-Viewer. All scripting, form-elements and DOM-Manipulations are using SVG and the viewer's internal Scripting-Engine only. The restriction to these core techniques will soon allow to deploy on other, SVG only viewer, such as the Batik-SVG-Viewer or X-Smiles. Both teams work also on enhanced scripting, interactivity and integration of other XML techniques, such as XForms and XSL.

Data-Sources and Workflow aspects

The core data-sources used for the project come from the swiss federal office of topography: VECTOR25 serves as the main vector-data source (rivers, landcover, administrative boundaries, etc), the situation (houses, road network, place-labels, cliff-drawing, etc.) uses the raster-based PK25 (pixel-maps) and the DHM25 contributes contourlines, spot-heights and a grid-based digital terrain model. The situation (black layer of the map) is still in raster format, because it either contains data not available in vector-format so far (such as the house polygons) or objects with more complex line-styles, such as the road network. All the labels (f.e. place-names) are still in raster format either. High quality label placement is still an unsolved topic. Future versions of the prototype, however, will replace more and more raster based objects with vector data.

The input data is delivered either in arcview shapefile or arcinfo coverage format. After conversion to the text-based ungenerate format and to dbase-files (for the attributes) a perl-script converts the data to the SVG-format. The output is converted using the swiss-coordinate system, with the y-axis inverted by prefixing a minus sign. This approach allows to easily integrate different geo-referenced data-sources, because they all share the same coordinate systems without having to use additional transformations. The beginning of the path geometry uses absolute coordinates while the following vertices use relative ones. The conversion script also allows grouping of objects with the same attributes, such as an object class. Each object gets an internal unique idenfier which links to the attribute-data, automatically converted to js-files, storing the data in arrays. Each unique group can be linked to a css-style, defining fill and stroke-attributes. All parameters needed for the conversion process are defined in a metafile containing the same prefix than the input geometry and attribute-data file.

After the conversion process the rest of the development process was mainly done using a simple text-editor such as nedit, vi and ultraedit. Hopefully, future svg development tools will help to develop mixed SVG and ECMA-script with coding support, validation and debugging features. The eSVG and Ormide Tool from Intesis is already very promising [1, JEZIC, 2002] regarding support of ECMA-Script. A combination with powerful WYSIWYG tools (such as Adobe Illustrator, CorelDRAW or JascWEBDRAW) would result in a very powerful toolset, in case they are well integrated with each other. The figure below shows the architecture of the system regarding the linked files (css, js). We tried to separate data from functionality and reuse some code, such as the code to generate drop-down selection lists.

Figure 2: Architecture of the interactive maps, linked files

GUI - Graphical User Interface

The whole webpage is filled by a "scalable" SVG with 100% width and height in the outer SVG element. This means that the whole user-interface is "scalable" to a certain extent. Of course the text-size would be too small if the user resizes to a very small window. The outer SVG's coordinate system uses screen coordinates with a 4:3 ratio. It contains two other SVG-elements that are defined with the swiss-coordinate system (simplified in a cartesic system and the y-axis inverted): The main map and a small linked reference map for navigation purposes, where the user can zoom and pan. An additional section below the main map serves as an "info panel" to show additional data.

Figure 3: Map Layout

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "" [
 <!ENTITY colorText "fill:darkcyan;">
 <!ENTITY knob "fill:white;stroke:darkcyan;stroke-width:2;">
 <!-- some entity definitions -->
<svg xml:space="preserve" width="100%" height="100%" onload="initMap();" onresize="resetFactors(evt);" zoomAndPan="disable" viewBox="0 0 1024 768"
  xmlns:a3="" a3:scriptImplementation="Adobe">
<script xlink:href="main.js" language="text/ecmascript" />
<script xlink:href="selectionList.js" language="text/ecmascript" />
<!-- GUI elements -->

	<svg id="overviewMap" x="820" y="60" width="200" height="156" viewBox="679000 -238000 4000 4000">
		<desc>Overview-Map Tuerlersee</desc>
		<g style="fill:none;stroke:dodgerblue;stroke-width:3;">
 			<use xlink:href="#RiversGroup" />
 		<rect id="rectForPlace" style="&rectstyle;" x="679900" y="-236500" width="2568.8" height="2000"
 			onmouseover="statusChange('click and drag rectangle to change extent')
 			onmousedown="beginPan(evt)" onmousemove="doPan(evt)" onmouseup="endPan()" onmouseout="endPan()"/>

	<svg id="mainMap" x="0" y="0" width="700" height="545" viewBox="679900 -236500 2000 1557.1" onmousemove="showCoords(evt);">
		<g id="relief" visibility="hidden">
			<image xlink:href="dtma.png" x="679000" y="-238000" width="4000" height="4000" style="filter:url(#filterHillshade)" />
		<g id="Landcover" style="fill-opacity:0.5;">
			<g id="Landcover_Z_BaumS" style="fill:lightseagreen;stroke:none;">
				<path id="Landcover0" onmouseover="showAttribData(evt,'Landcover',0)" onmouseout="showAttribData(evt,'Landcover',0)"
					d="M682792.9 -237324.1l17.199  ..... .5l5.9 7.299z " />
				<path id="Landcover1" onmouseover="showAttribData(evt,'Landcover',1)" onmouseout="showAttribData(evt,'Landcover',1)"
					d="M682867 -236966l-42.5 ..... 141.899l-65 26z " />
		<!-- additional geometry -->
<!-- additional GUI elements -->

Code-Snippet: Nested SVG Elements for GUI, main-map and reference-map

The GUI-Elements (checkboxes, selection-lists and knobs) are all implemented in native SVG with the help of events and ECMAScript. Although, at first glance this seems tedious, it ensures browser and platform-independency and guarantees a consistent "look and feel" in all operating systems. And, as a map-author, you get full control of every single aspect a GUI-component looks like. Of course it would be welcome if SVG-viewer offer support of the XForms language, to help developers save time. X-Smiles [5, XSMILES, 2002], a Java-based XML-viewer for XHTML, SVG, SMIL, X3D and others already supports XForms and looks very promising. And other viewer, like Adobe SVG Viewer and Batik are likely to follow. SVG's strength will be fully exploitable if it is integrated with all other important XML-standards, quite similar to the way the X-Smiles team is working on. Another option to efficiently use GUI-Elements in SVG is "SVGUI" a project led by Kevin Lindsey [2, LINDSEY, 2002]. Kevin works on implementing a separate namespace for GUI-elements. The foreign-namespace is parsed, triggered by the onlad-event, and replaced by the corresponding SVG elements and ECMAScript functionality.

Selected Features of the Prototype

The prototype allows to show attribute-data whith mouse-over events, while exploring the map. To switch between different layers for the mouse-over events it is very useful to change the pointer-events-attribute of the non-active layers to "none". The user can locate an element by using a selection list. The map is automatically centered either around the objects bounding-box (you can get that with the element.getBBox()-method) or by an rectangular area defined around the feature.

The analytical hillshading is done using a <feDiffuseLighting/>-filter with a <feDistantLight/> as a child-element. The user can set azimuth and elevation of the lightsource by using the knobs in the GUI-section of the map. The dtm data was sliced in a GIS-system to 256 values and exported to a png-image. The height information is stored in the alpha-channel of the image.

 <!-- hillshading filter -->
 <filter id="filterHillshade" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%" filterRes="510">
  	<feDiffuseLighting in="SourceAlpha" diffuseConstant="1" surfaceScale="200">
		<feDistantLight id="lightsource" azimuth="225" elevation="45" />

Code-Snippet: filter-definition for an analytical hillshading

<g id="relief" visibility="hidden">
	<image xlink:href="dtma.png" x="679000" y="-238000" width="4000" height="4000" style="filter:url(#filterHillshade)" />

Code-Snippet: filter assignment to the image containing the dtm-information

function setAzimuth(event) {
	if (event.type=="mousedown") {
		azimKnobStatus = 1;
		azimKnob = event.getTarget();
	if (event.type=="mousemove") {
		if (azimKnobStatus == 1) {
			myXdiff = myKnobCenterX - (event.getClientX() - mapOffsetX) * scaleFactor;
			myYdiff = myKnobCenterY - (event.getClientY() - mapOffsetY) * scaleFactor;
			direction = (180 - (toPolarDir(myXdiff,myYdiff) / 3.14 * 180))*-1;
			azimValue = direction;
			if ((direction &lt; 0) && (direction &gt; -90)) { 
				azimValue = direction + 90;
			if ((direction &gt; -360) && (direction &lt; -180)) {
				azimValue = 360 + direction + 90;
			if ((direction &lt; -90) && (direction &gt; -180)) { 
				azimValue = 270 + 180 + direction;
	if (event.type=="mouseup") {
		azimKnobStatus = 0;
		myLightSource = svgdoc.getElementById("lightsource");

Code-Snippet: ECMA-script function to turn the knob and change the azimuth-attribute of the filter-definition

The cross-section generation is a bit more complex and will be explained in detail in another article at the webpage. First of all the user has to draw the cross-section line on the map (the line can have more segments). An algorithm densifies the line, reads the z-value along the line, using the coordinates from the densify algorithm and a bilinear interpolation function to get the correct z-values between the four surrounding grid-values, according to the location of the point within those four grid-corners. Another function draws small rectangular slices to generate the profile, adds gridlines and event-handler to show data distance and elevation data on mouse-over. If the user clicks on a slice a script shows the current position in the map along the digitized profile line.

Code Optimization

Good SVG code is not only compact and readable but also allows for efficient maintenance - f.e. to quickly change attributes and properties centrally. Following is a "catalogue of measures" that helps to ensure small file sizes and easy maintenance.

Composed complex line styles

Figure 4: Complex Line-Styles composed of three lines sharing the same geometry, but with different line-styles
Source: [4, WINTER/NEUMANN, 2001]

Figure 5: Complex Line-Styles composed, Example SVG

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "" [
	<!ENTITY roadBelow "fill:none;stroke:black;stroke-width:10;">
	<!ENTITY roadAbove "fill:none;stroke:yellow;stroke-width:5;">
	<!ENTITY roadAboveSmall "fill:none;stroke:black;stroke-width:1;">
	<!ENTITY railroadBelow "fill:none;stroke:black;stroke-width:6;">
	<!ENTITY railroadAbove "fill:none;stroke:white;stroke-width:3;stroke-dasharray:10,4;">
<svg width="310" height="390">
	<g id="railroads" style="&railroadBelow;">
		<path id="railroad1" d="M44.32,0.047c0,0,26.77,305.973,253.425,387.671"/>
		<use xlink:href="#railroad1" style="&railroadAbove;" />
	<g id="roads" style="&roadBelow;" >
		<path id="road1" d="M0.485,379.5c0,0,60.274-249.315,308.219-286.302"/>
		<use xlink:href="#road1" style="&roadAbove;" />
		<use xlink:href="#road1" style="&roadAboveSmall;" />

Code-Example: Reuse of existing geometry to compose complex linestyles; Code for the above svg-graphics.

The Swisstopo Map-Browser project

While interactive maps are advancing and getting quite popular, there is still a high demand for printed paper maps. Paper maps are superior in several aspects: they are mobile, can be large format, don't need batteries, feature a high resolution display and are usually more dense in content than their counterparts on screens. Printed maps are still very much used for planning purposes and orientation within the terrain, especially for mountaineers. It is also a matter of fact that online map-stores (with additional metadata, search-engines and a preview of the map) are more and more frequently used during the decision process when buying a paper map. A good map-browser can assist the user in choosing the best map needed. The Swiss Federal Office of Topography is famous for it's high-quality paper-maps, esp. for their way of terrain and cliff representation, and offers map series in different scales, with the scale 25.000 as a base scale.

The project presents an innovative way of browsing map-informations, by using the 25.000 map series of the Swiss Federal Office of Topography. The map browser shows the following important metadata, useful for choosing and buying a map-sheet:

The browser also features toggling map-layers, a linked reference map for zooming and panning and the display of map-feature-attributes, such as object names (currently "Kantone" and hydrology). Currently the browser only contains information on the 25.000 scale map series, other scales, however, could quite easily be integrated, if needed.

Screenshot Prototype Swisstopo Mapbrowser

Figure 6: Screenshot of the prototype "Swisstopo mapbrowser - Link to the project site
© Bundesamt für Landestopographie (JD022306)

The input data was exported using the same conversion-script mentioned above, at the Tuerlersee-Project. The map-sheet layer and the administrative boundaries (in our case the cantons) had been overlayed in a GIS-system in order to get the information which administrative units are covered by a map-sheet and vice versa. ECMAScripts handle the way the metadata is displayed in the interactive legend.

Other useful features could be added to the existing prototype: It would definitely be interesting to allow the user query maps by placenames or combine searches with other metadata. Currently only the administrative level of "Kantone" is overlayed with the map-sheet boundaries. It would be useful to add districts and communities. Additional topographic features (such as mountain peaks, cities and traffic-network), maybe also combined with levels of details, would make the base map more attractive. Finally the browser could be integrated with a map-store and would allow the user to graphically select map-products.


The above two prototypes have shown the huge potential, SVG offers for interactive maps. By using open standards and open-source or free software, also smaller companies and universities can afford to serve interactive maps, because there are almost no software licensing fees involved. However, the projects are still in an early stage and are only "scratching the surface" in terms of what really could be done. Some of the planned features are already listed above. So far, we can only serve limited map-extents. One of the next steps would be to generate the map-content out of larger spatial databases, such as the PostGIS [3, POSTGIS, 2002] extension to the Postgres Database. Finally there are still open question in terms of protecting map-content, ensuring copyright and data licensing fees.

Authoring complex SVG projects without powerful authoring tools, that also support coding and debugging, can be a pain. While XML-editors can help coding and tracking errors in SVG-files, the support of ECMAScript debugging is still in an early stage and only covered so far by the eSVG tools. The urgent need for SVG development tools opens new opportunities for software vendors in the graphics and development tools industry. While the SVG-Viewers are rapidly maturing, there is still no viewer available that implements the whole SVG 1.0 standard. We hope that the market-penetration and acceptance of the SVG standard will evolve rapidly for being able to serve even better and more interactive maps to the map-user. If authoring and viewer tools as well as SVG-content mature, SVG can have a bright future in interactive graphics and in particular for interactive maps.


[1] JEZIC, Damir (2002): "eSVG - SVG for Embedded Systems". Available at

[2], LINDSEY, Kevin (2002): "SVGUI - a graphical user interface framework written in SVG and ECMAScript". Available at

[3], POSTGIS (2002): "PostGIS - Geographic Objects for PostgreSQL". Available at

[4] WINTER, Andre and Andreas NEUMANN (2001): "Kartographie im Internet auf Vektorbasis, mit Hilfe von SVG nun möglich". Available at

[5] X-Smiles Development Team (2002): "X-SMILES - an open xml-browser for exotic devices". Available at

Valid XHTML 1.0!