GML and SVG: from content to presentation

Marian de Vries

Delft University of Technology,

Department of Geodesy, Section GIS-technology

Thijsseweg 11, 2629 JA  Delft, The Netherlands

Tel (+31) 15 2784268

Fax (+31) 15 2782745




SVG has a lot of potential for the publishing of geographic (or "spatial") content on the Web. Many examples exist of user friendly, interactive interfaces based on a combination of SVG, HTML and JavaScript. Basic functionality like "pan", "zoom", "identify" and visibility control (switching on and off of map layers) is not a problem. If there are bottlenecks these are mostly in the field of performance (loading time) or they concern differences between (versions of) browser software that have to be handled.


At this moment SVG seems especially suitable for sites that show the more or less pre-defined content of one provider. It also helps when file (or stream) sizes are not too large. For other Web Mapping situations (retrieving data of more than one provider, analyzing and editing) more work has to be done. Important issues are:

1       Ways to reduce loading time (as perceived by the user). A strategy could be to store the SVG path or shape elements in the database. Synchronization with the real (geographic) data can be enforced by stored procedures etc. Loading time will be reduced because the on the fly transformation of feature instances into SVG can be skipped.

2       Better possibilities to change the rendering order of SVG elements (or element groups). There are ways to do this, but some methods have consequences for event handling (grouping and referencing with <defs> and  <use>), or they involve DOM actions for all individual elements of a group ("removeChild", "insertBefore", "appendChild"). Maybe the "z-index" construct should be added to the SVG specification after all.

3       Better support by plug-in software for inbound linking into SVG (addressing SVG fragments by their id). At this moment (January 2002) only Apache"s Batik seems to be able to handle this. This could also be a solution for the rendering order issue.


SVG is "only" the graphic format. The geographic information itself is stored in proprietary GIS or CAD file formats or in object relational databases (Oracle Spatial, Informix Spatial etc.). This raises the question of the transformation from the data itself into SVG. This can be done as a batch process or "on the fly" with SVG data and (dynamic) HTML pages as a result.

At the TU Delft we are experimenting with the transformation of GML into SVG. GML (= Geography Markup Language) is an important initiative of the OpenGIS Consortium. It is a domain specific XML vocabulary meant for the storage and exchange of spatial data.

The OpenGIS GML specification is basically a set of XML Schema documents with element declarations and type definitions plus a hierarchical structure for the relationships between types. In this way the specification offers a framework that can be used by organizations to make the application specific XML Schema(s) for their own GML implementation. User organizations do this by extending the basic GML object types as defined in the specification.

GML can play a part in geographic data exchange in a number of ways:

-        as an "offline" exchange format (downloadable files or on CD) 

-        as an "online" format for retrieving and maybe even updating spatial data. Another OpenGIS initiative is important here: the Web Feature Server specification. The Web server outputs GML as response to a client request.


We chose XSLT for the transformation of GML into SVG. Some components of the GML viewer were hard coded: the rendering order of the map layers and the styling parameters (color, fill, line width). For the "identify" operation the original GML data is queried with the help of a unique id.

The next step will be to make a viewer that will consist of a generic 'core' in combination with some interactive modules that make it possible for users to change the rendering order of the map layers, and to change the classification and/or styling attributes for feature sets.


It proved not "trivial" to write transformation software that can transform GML into SVG regardless of its data structure. This is because of the fact that feature and attribute names are not fixed, but vary from organization to organization. Also the hierarchical structure (nesting of features and feature collections) is not the same for every GML implementation.

The XML application schema(s) that describe the structure of the GML play a crucial role in this respect: the transformation software will have to read the implementation specific XML Schema document or documents first, before it can 'understand' and transform the GML data.