SVG Dynamic Cartographic Application

For the SVG Open 2005 conference

Keywords: php, mysql, SVG

Annie Danzart andChristine Potier
Associate professors
Ecole Nationale Superieure des Telecommunications
GET-UMR-5141-Computer Science Department
45 rue Barrault
75634 Paris cedex 13


This paper treats the development of dynamic applications in cartography on the internet using free software tools : SVG, MySQL, PHP, Javascript.

The first part presents a specific cartographic application making it possible to visualize information on population density in France. The data are stored in a Mysql database. SVG maps are generated "on the fly" by querying the database and processing the result with php scripts.

After thorough analysis of the mechanisms involved in this application presented in part two, we were able to create an automatic generator of such applications, Cartogen, presented in part three.

Table of Contents

1. A Specific Cartographic Application
     1.1 Requirements
     1.2 Avalaible information
          1.2.1 Data
          1.2.2 Transfer of the administrative hierarchy to the database
     1.3 Structure of our application and how it works
          1.3.1 How the application works
          1.3.2 Queries and generation of SVG maps
          1.3.3 Optimisation of the application
2. Generalization
3. Cartogen software
     3.1 Configuration definition by using Carto-UI
     3.2 Cartographic Website Generation with Carto-XML
4. Conclusion

1. A Specific Cartographic Application

The aim of the application is the demography in France. We want the user to be able to visualize demographic information about the area he is over or in response to a precise request. The choice can be made either by a precise demand or by some navigations.

1.1 Requirements

We wish to have the following characteristics:

1.2 Avalaible information

1.2.1 Data

The following information is available for the 36670 cities of France, the 95 departments and the 22 provinces. We have two kinds of data : the constant informations of the cities, departments and provinces (name, shape, ...) , and the specific information of the application (population, density).

1.2.2 Transfer of the administrative hierarchy to the database

In order to create our application and further to generalize it to another set of data, we decided to take advantage of the hierarchical nature of the administrative information (Provinces > Departments > Cities). We also wanted to separate general information from specific information. From this point of view, we created a database with the following tables :

To represent the general information

  1. at the higher level, a table of the Provinces with, for each of them:
  2. at the intermediate level, a table of the Departements with, for each :
  3. at the lower level, we have a table with all the 36670 cities of France with, for each of them :

For the specific information

  1. at the higher level, a table of the data for Provinces with, for each of them:
  2. at the intermediate level, a table of the data for Departements with, for each :
  3. at the lower level, we have a table with all the cities of France with, for each :

The shapes of the administrative entities are official administrative data. They were initially given with a polyline which was a sequence of points in absolute coordinates. In order to create polyline SVG paths easier to use (with smaller numbers), we have computed the relative path coordinates. Hence, we use two fields containing the coordinates of the starting point of the line and a field containing the computed SVG path.

The min-max box of a shape is recorded in 4 fields : xmin, xmax, ymin, ymax. These values have been computed as extrema of the points of the SVG path. We use them to compute the SVG viewBox. We calculate the viewBox by adding a border to the min-max box.


Figure 3: Database structure

In addition, we defined a table containing the geometric information of the rivers. We did not have the required numerical information about them. So we computed the SVG paths describing the rivers by the following algorithm: by using a first version of our own application, we sent a query to have all the cities whose name contains the word "Loire" (for example). Then, we sorted the list of the barycenters of the results. Then we computed the B-spline cubic interpolation by solving a linear system. We decided to use a B-spline cubic path because it is smoother than a polyline and is well suited to the real shape of the river.

Note that the rivers will always be displayed, whatever the level.

1.3 Structure of our application and how it works

Our application is in fact a dynamical web-site. We only used free softwares for this application. Server-side, we have an apache/2.0.53 server (Unix), with the php/5.0.3 module and mysql/4.0.20 database. We do not need to use a GIS for this application.

The 2D-graphics are obviously in SVG in addition with Javascript for the animation. Javascript is used to perform the mouseover events by displaying the corresponding information. The mouseclicked events and the submit-form events call php scripts. Our Javascripts respect the ECMAScript standard so as to be compatible with most browsers.

1.3.1 How the application works

The complete application process is described on figure 4:


Figure 4: Application process

The home page is "". At each step of the navigation, the url of the page will be the same followed by a varying arguments list. The general process is

  1. the php script builds a mysql query and sends it to the mysql server
  2. the mysql server sends the answers that match the query (SVG paths, data for drawing and textual information) to the Apache server.
  3. the php script processes the data and generates the SVG code : it uses the transmitted paths to build "on the fly" the SVG paths. It computes the viewBox. A textField with the information to display at the mouseover event is associated with each path. Moreover, this SVG code is encapsulated in the invariant tags.
  4. finally, the Apache server sends the SVG code embedded in the index.php page to the browser, with the javascript code.

The user can then navigate through the map, selecting a province and then a department. At each time, this creates a new query to the database and the displayed information is more and more detailed. At the last level, we will see the contours of all the cities of the chosen departement.

He can also send a specific query by using a form. Once the user has chosen the query, the mechanism for displaying the map is the same as in the navigation mode. The only difference lies in the color which outlines the chosen items.

1.3.2 Queries and generation of SVG maps

All the SVG maps of our application are dynamical. They are the result of queries sent to the database.

We use two kinds of queries :

  1. quasi-static queries : navigation generate an instanciation of query-types whose prototype is a priori defined in the php scripts. For example, if the navigation consists in going from the first level (France) to the second level (Provinces) using a mouseclick, the ID-number of the chosen province is unambiguously determined. In that case, we have pre-formatted queries where it is only necessary to add the ID-number of the selected province.
  2. dynamical queries : on the web page of our application, it is possible to use a form to determine the criteria for the items the user wants to highlight. Once this choice is made, the query to the database is built from scratch.

In both cases, the query provides all the necessary information in order to generate the SVG path and to use the adequate Javascripts.

1.3.3 Optimisation of the application

  1. Use of indexes in the database
    During the development of our application, we have compared its performances with and without indexes. At the lower level, during the navigation or sending a query, no important difference has been observed.
    However, if we send queries at the higher level (on the whole of France) in order to display cities (lower level) with a chosen criteria, we see a notable acceleration of the process with indexes. Particularly in the case where a lot of cities are matching the query, we observe that with indexes the query is acknowledged and the results are displayed, whatever the number. Without indexes, the process was interrupted and nothing was displayed.
    The difference lies probably in the time (generaly 30 seconds) the Apache server allocates to execute a php script.
  2. compression of the SVG maps
    We wanted to evaluate the advantages of using SVG zipped files. We compared how quickly the map was displayed with compression and without. We conducted our experience a 100 times on 10 different maps. We made it around 100 times for the same map, and this for 10 maps. To optimize the compression process, we used the gzwrite() php function to create a zip file of the SVG source. We selected the level 7 of compression to get the best compromise time consuming/file size. We obtained the following results averaged out :

    Figure 5: Optimization with compression

    In fact, the time spent to compress the SVG flow is negligible compared to the time of transmission and displaying. Moreover, it crucialy depends on the traffic on the net. However so far as it generates smaller files, it uses less resources in the net.
    This is the reason why we prefered to keep it in our process.

2. Generalization

We have developed some variants of this dynamical cartographic website with the same concept of querying a database containing hierarchical geometrical data as well as textual and numerical data. To build such a cartographic website, we thought useful to produce an interface usable by a designer or webmaster with little knowledge of html, SVG, PHP and MySql. All that is required of the designer is a very good knowledge of the database structure and of course the elements that he wants to display.

The demographic application provides the basis for future applications. As a result, we were able to separate the invariants and the specifities of each application, which makes it easier to automatically generate a new one. We identified three major components :

Hence, we have implemented a Java software with which the application designer will be guided to give all the information necessary to define the three components described above.

In so far as the website generates on the fly SVG flows, the database must contain :

The geographic information on which we want to zoom must be hierarchical. Thus, the database must explicitely contain the links describing the hierarchy of the information. This hierarchy allows SQL queries to be performed easily.

In our cartographic applications, a map is defined as a superposition of layers in which only one is enabled at a given time. As a website may contain several maps and as an event in a layer of a map may update another map, the whole of the process of navigation and the switching rules in a SVG flow must be known precisely.


On a displayed screen, the different zones are called « containers ». A container can enclose a stack of graphic layers which are visible or not. For example in the previous website, there are 5 containers (see figure 1). The container on the left encloses the layer of the country, the layer of the regions and the layer of the departments. These layers are called « panels ». They are event sources whose action must be defined in the interface.

3. Cartogen software

A software named « Cartogen » has been implemented in order to automatically generate a cartographical website.

Cartogen software generates a cartographic website in 2 steps :

3.1 Configuration definition by using Carto-UI

This graphical interface written in java is used by the webmaster to parameterize the functionalities of the website (layers in the containers, hierarchy of the navigation,…). This software runs in four steps :

The three first steps correspond to the application engine.

When all the arguments are defined, these values appear in a dialog window where the webmaster may change the text if he is not satisfied.


Figure 8: Panels definition

3.2 Cartographic Website Generation with Carto-XML

Once the configuration is done, the webmaster can create the website by launching the cartogen engine. Carto-XML needs to know the name of the XML file, the destination path (a path accessible by the http server) and the name of the directory that will contain the scripts.

At the destination, carto-XML puts all the needed and created files :

Once the website is generated, it is always possible to modify it by downloading the configuration saved in the XML file and modifying it with Carto-UI without making it again from the very begining.

4. Conclusion

The dynamical cartography in internet with free software offers a lot of possibilities to observe and to analyse phenomena by getting numerous maps in a very easy way. We have built cartogen, a software which allows to a non-specialist to build such an application from the knowledge of a database including all the required data. With cartogen, we have already built some applications on demography, elections, ... in France. Those applications allow the user to query the database via navigation and simple forms.

However, for the moment, the form produced by cartogen can not process all types of forms. The possibility to produce multiple choices forms has not been implemented yet. Our goal is now to give this possibility to the cartography website designer and to use the animation possibilities of SVG.

web-sites :

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