Experiments with SVG
for an intranet interactive graphic application prototype

Robert Rivière
French Ministry of Transports
Centre d'Etudes Techniques de l'Equipement d'Aix-Les Milles
BP 37000 13791 Aix-en-Provence Cedex 3


Inside the French Ministry of Transports, a study about deploying a Road Management Information System is being carried.
During year 2001, we have built a prototype of an application for graphical displaying and editing localized road objects. As our organization global strategy is to develop new applications on top of Web architectures, the goal of this prototype was to validate the use of SVG technology for enabling simple graphic interactions in this context, and test vector graphics generation and use from XML data.
This work was made with the help of a subcontracting company specialized in XML technologies.
This paper is about a technical presentation of the prototype, showing how SVG has been used, what have been implementation questions and choices, and what kind of functionalities will be brought to users.
Tools used are the Adobe SVG Viewer V3, completed with some EcmaScript extensions developed by the subcontractor, and XSLT technology for initial data transformation.
Furthermore, we try to identify some general guidelines for Web interactive graphics mixed with HTML applications architecture.


During year 2000, to improve its management of its 50,000+ PC running several hundreds of applications, the French Ministry of Transports decided to start to migrate from a standalone or client/server architecture towards a thin-client Web architecture.

If there are nowadays around the world lots of examples of alphanumeric applications working under this kind of architecture, they aren't so much in the graphics or engineering domain.

This is why we started to experiment with SVG: we wanted to check if in a "almost" (in the sense that SVG displaying still requires a plug-in) thin-client Web architecture, we could achieve a correct level of interactivity, more developed than the "single-click" paradigm.

Road Management is for us one of the first technical domains to be concerned by this migration. Applications now in use are some old ones, still inspired by a DOS design, having some outdated constraints on data structure and functionalities. So it was decided to migrate towards an Information System architecture, including as far as possible some interactive graphics capabilities, which, even if they were very basic, would be better than what users are now used to.

In this paper, rather than showing tips and howtos about SVG programming, we're going to try to identify some design issues and generic choices for building interactive graphics web applications, as they were proposed and tested while implementation by the subcontracting company.

Aims of the prototype

Three kinds of applications are today in use in road management domain:

For the future information system, we wanted to check if in a Web architecture we could make these three kinds of view cooperate inside the same global application.

So we started to build a prototype able to show these 3 views simultaneously, looking like the following picture:

An artist view of graphical interface

An artist view to what the GUI could like - inside a Web Browser window

Prototype architecture

As we were building an intranet information system, we controlled what kind of platform would support client, so the prototype could be built on top of following standards and tools:

Readers will probably be quite aware of XML/SVG technology benefits. But for us, a major advantage was that client interactivity may be achieved with EcmaScript and DOM primitives on XML elements: as Web-applications are a global choice for our organization strategy, our technical teams will be familiar with DOM coding, so programming with SVG would require a smaller effort.

On the other hand, in spite of showing a 2D view looking like a map, we didn't want to implement sophisticated SIG primitives, neither include a cartographic engine inside our application, to cope with thematic presentation or labelling. Instead, we decided to overlay our application active objects as vector data on top of a pre-generated static raster image, using it simply as a map for user guiding. The choice of a static background map shouldn't be a major drawback as data it shows don't change very often.

So we could concentrate on building an application dealing with interactive schematics rather than interactive mapping.

We also wanted to experiment with an XML data flow form server to client. So a data sample was built in XML to be transformed to SVG following the global XML model, i.e. by XSL transformation.

As some representation styles and some symbols would obviously be used, we planned to store them in CSS stylesheets and in separate SVG file (called 'Symbol Library'), like in the following picture:

Data flow for the prototype

Data flow for the prototype - In real application, XML data here pre-existing will be of course dynamically generated from requests to a database.

Elements of interactivity

Beyond basic point of view changes managed by the viewer (zooming and panning), we also wanted to give user some tools to browse data without requiring client/server communications:

If it was clear that each of these functionalities could be implemented in SVG and javascript, we didn't know how many objects could be managed this way (performance problem) and how to design data and scripts procedures structure to keep a clear and maintainable architecture (architecture problem).

Besides, it also meant that preliminary to browse data with the navigator, the application had to make the user define the batch of data he wanted to work with. We'll see later that this had an impact on the global design.

Specific attributes transport

The first question to answer was: how to carry application attributes with SVG objects description ? As road objects we manage had geometric attributes we could obviously translate to a SVG equivalent (size, position, symbol, style, ...), they also had some specific attributes we couldn't express directly in SVG vocabulary: for example, their curvilinear abscissa along a road, or their position according to a hierarchical referencing system.

We didn't find a basic implementation, often seen, using javascript arrays to store data about SVG objects very satisfactory. The main reason was that we wanted to keep, if possible, object structuration up to SVG structuration: for example, if an object could be shown as a <polyline>, with a vertices coordinates attribute, a style attribute, an identifier attribute, ..., it seemed interesting to append our specific attributes to these.

The mechanism we used to do this was to reference to a specific namespace to embed our attributes inside SVG elements, making this way an ad-hoc extension of SVG:

<polyline class="sirTroncon" 
e:idtrrte="130005875" e:sdd="15218" e:sdf="15754" 
e:prd="15" e:prf="16" 
e:xd="831" e:xf="426" 
stroke="red" stroke-width="100" fill="none" 
points="863586 1986343 863640 1986374 863812 1986472 863962 1986582"/>
<!-- e: namespace attributes are application specific -->

As specified in SVG Recommendation, on one side the viewer would process SVG elements and attributes, silently ignoring extension namespace data, and on the other side e: data could still be accessible with JavaScript DOM primitives.

So the goal, to be able to carry application attributes with objects in order to display them inside a tooltip or a form, without interacting with the server, was easy to achieve from scripts by calling DOM2 primitive getAttributeNS('e:', ...).

About global application design

This design choice had an unexpected effect: we noticed that, to achieve ability to locally work with application attributes in the navigator, we had in fact to send to the client a batch of data which were a copy, rewritten in (extended-)SVG but logically equivalent, of data managed by the server.

To clarify this, let's detail each of the steps:

  1. the application makes the user identify a batch of data he's going to work with: for example objects from a given class along a given road, objects inside a given geographic area, etc...
  2. the server builds an (extended-)SVG representation of these data and sends them to the client
  3. once the data have been sent to the client (navigator + SVG viewer + JavaScript engine) , the user works with them for a "long" time (i.e. an important part of a work session)

The question then is a question of responsibility: from the moment we have reference data stored in the server, and a copy of these sent to the client, for a "long" time, for browsing them and eventually modify them, who - the client or the server - is responsible of their management?

We can see two approaches:

  1. Once the server has built the XML/SVG formulation of the working data and sent them to the client, he forgets about them and delegates their management responsibility to the client.

    This is what we could call a "XML centric" client architecture. This is a very powerful model: by using client scripts, virtually all interactivity mechanisms can be implemented, data can be modified locally, and application becomes more modular: server's job is clearly different than client's job. If a batch of changes is made on data, the only communication involved is sending an update to the server.

    But we found this architecture a bit extreme:

  2. On a more conventional approach, we can consider that XML/SVG data are a "read-only" copy of the server data. The server keeps its responsibilities on managing the data.

    Browsing data is possible in the same conditions as in the other case.

    It is for editing data that the mechanisms become different: as for usual applications, this will be the server that manages dialogs and keeps the state of operations sequence. This leads to less client autonomy, more exchanges between navigator and server, but will probably be much easier to develop in usual frameworks.

    Nevertheless, as we'll see later, XML/SVG technology will still enable a richer than "simple-click" interactivity for editing data.

We chose for the prototype the #2 design. There are probably some applications that will go through #1 choice, enabling some new powerful paradigms for web applications.

What we simply want to tell is that this design choice has to be clarified as soon as possible.

Other problems, chosen solutions and implementation

Objects behaviour

We've seen that using a specific namespace enabled us to encapsulate application attributes inside SVG entities, making them look like objects. By the way, we found also interesting to associate some "behaviour" to these objects.

The foundations are still of course DOM events. But direct use of them can quickly lead to some complex - difficult to read, to understand and to maintain - SVG code.
What if, for example, we want some elements to be clickable to put them in a selection, changing them to a red color, to be able to drag them, in addition to default behaviour of displaying application attributes in a form ? Stacking several calls to javascript procedures, with ad hoc arguments, in onClick="..." attributes would quickly become confusing.

Instead, the way we chose to experiment was again to extend SVG with "behaviour" attributes and elements.
We defined a set of tags that could be embedded in or associated with SVG objects. A clear benefit of this was that a precise description of what can be done on objects is made in an XML syntax, much more expressive and structured than sequences of procedure calls.

Here are some of elements we defined and use in "interactive SVG" i: namespace:

Here are some examples:

<!-- displaying a symbol -->
<!-- e: namespace carries application attributes,
     i: is for declaring behaviour : this object has a tool-tip associated, 
        is selectable and is invariant to zoom operations -->
<use e:type="sir:pr" e:id="id-A0050-909" e:sd="2386" e:nopr="3" e:cote="d"
  id="id-A0050-909" class="PR-d2D" xlink:href="#sir:pr-d" 
      <i:tool-tip text="PR 3 (d)"/>
<!-- loading on demand a raster background, depending on current zoom-level -->
<image height="105050" width="140000" y="1900330" x="746660" 
         <i:level above="0.05">
            <i:set-attribute name="xlink:href" value="a-closer-image.png" />
            <i:set-attribute name="height" value="15900"/>
            <i:set-attribute name="width" value="21900"/>
            <i:set-attribute name="x" value="853000"/>
            <i:set-attribute name="y" value="1978860"/>
         <i:level below="0.05">
           <!-- ...etc... multiple loadings possible depending on level of zoom intervals -->

Of course, these declarations have to be translated to DOM events to be processed by the navigator or the SVG viewer.
This is done by an initialisation routine launched when loading the SVG document. This routine job will be to associate DOM-events attributes and javascript routines to SVG graphics objects (for example, transforming <i:select /> or <i:tool-tip ...> to onclick="...", onmouseover="...", ...)

Windows synchronization

One of the goals of the new Information System was to give ability to show simultaneously several views of the data (alphanumeric, 1D, 2D), while maintaining them coherent in case of an update.

By the way, the graphical views should be optional, to keep application usable if the SVG viewer happened to be unavailable, i.e. on low profile devices.

The architecture we designed to make the different windows collaborate was based on a registering and callback-on-event mechanism:

  1. A global object, called the SelectionStore, is created at first loading of data. It will be responsible for managing windows synchronization.
  2. Every subwindow, (alphanumeric HTML or graphic SVG), will have to embed a callback routine for treating updates. When created, the initialisation part of the subwindow will have to register this routine to the SelectionStore.
  3. Whenever a change happens in a subwindow, the SelectionStore has to be informed by a predefined subroutine, and then it calls back all registered functions, making other subwindows aware of the change and launching view updates.

Subwindows synchronization principle

Subwindows synchronization principle. callBack{1,2}() and dumpObjects() are routines embedded in subwindows for managing updates.

Special difficulties

Despite XML, SVG and JavaScript power, there are a couple of things we couldn't manage to make work well or had difficulties to implement. Here follow the main ones.

  1. Axis coordinates orientation

    This problem is often pointed out, especially for mapping applications: usually the Y-axis is pointing upwards, and it's pointing downwards in SVG standard.

    Of course, we can combine viewPort definition and scaling transformations to invert Y-axis. But for real applications, it quickly becomes confusing to manage. For example, a global inversion will also invert text, which is probably not desired.

    Hopefully, future SVG standard evolutions will address this.

  2. Overlapping objects

    In a schematic drawing, it'll be more or less unavoidable that objects will overlap themselves, with sometimes some of them completely hiding others.

    Incidentally, we chose as basic rule for our GUI to make user browse objects attributes by clicking on them. But if an object is partially (resp. totally) hidden by another one, clicking on it becomes difficult (resp. impossible).

    We hoped to be able to implement amechanism where the GUI detected that several objects where under the pointer when the user clicked, eventually asking in a second step which object he desired to browse from a sub-list.

    But we didn't find how to make the onClick event "go through" several stacked objects and trigger javascript routine on each of them.

    To get around this, we introduced a pseudo-object to group (in an application sense, not in SVG sense) objects that may overlap each other because they were "near".
    This pseudo object was computed on data generation step (i.e. on the server) and had a dedicated symbolic representation and behaviour:
    It could be "opened" if user clicked on it, and display its content which was in turn original objects themselves.

    example of overlapped objects grouping

    An example of overlapped objects grouping - on the left, cursor on the group symbol shows the group tool-tip ; on the right, clicking on the group symbol "opens" it and then shows contained objects

    As the picture shows, this solution isn't totally satisfactory, for two reasons:

  3. Mapping window coordinates to user coordinates

    We chose to work as far as possible with geographic coordinates for SVG objects. This means that each graphic entity coordinates were somewhat large numbers (about 1,000,000), due to geographic reference system used (Lambert II). The mapping to screen coordinates was made by the viewer by defining a viewport.

    We found that navigator and SVG viewer arithmetic could cope with these large numbers with no problem.

    But some operations needing screen-pixel precision, like zoom-constant, were difficult to implement because of precision problems on getting current view zoom and pan, after user changed them.

    Moreover, we also wanted to be able to center a view on a given element. It appeared as a quite complex operation, because of all viewports and transformations that may be applied to current view.

    For us, these problems would be much simpler if there was a way to get current view extent in user-coordinates, directly from inside the viewer. It would be more precise and especially a lot faster than recomputing it from the JavaScript side.

Still to experiment

About overlaying vector data on top of raster background, we still have to find a server able to distribute on demand these backgrounds.

A more and more largely used technology in our organization for raster maps web-publishing is the proprietary ECW format, with its associated plug-in. These products achieve a very high compression ratio for raster data, and a nice dynamic viewing from navigator plug-in.

As SVG viewer may be transparent, we plan to experiment overlaying it on top of an ECW plug-in in a navigator window. This way, vector data would be displayed by the SVG viewer, raster background by the ECW viewer, with a coupling between the two to synchronize views extent when changed by the user. This task needs in particular a precise and efficient routine to get actual limits of the displayed SVG window, problem raised in above paragraph.


The client typical platform for this application should be a mid-range PC.

We found that with our prototype, on a such device, we could manage about a couple of thousands objects, with a satisfying response to user actions: zoom and pan, clicking on objects.

On the other hand, we found that moving objects by dragging them was too slow to be usable, mainly because of window synchronization architecture we chose. Things could probably be optimised by bypassing this callback mechanism for this particular task.

About SVG exchanged volume, we found that after gzip compression, it went as low as about 40 bytes per object - including geometry and application attributes. This is quite acceptable for an intranet application.

About server side operations, we made some small experiments with Java Xalan XSLT processor, run as standalone program (i.e. not embedded in a web server engine). We found that transformation took several seconds to generate SVG data. This is clearly much too long to be used for a real working application. Hopefully XML-oriented publishing environments like Cocoon will offer more performance.

Robert Rivière, May 2002

Valid XHTML 1.1!