Links between SVG and open or free tools in an online GIS

Case study : generate wide format printings with a SVG-based GIS


Table of Contents

Introduction
From GIS files to SVG
Server side generation
Why these choices ?
SVG visualization and manipulation in GIS
How to display SVG
Add interactivity
Advantage and drawback
Including raster files
Mapserver
Pros and cons
From SVG to PDF
Conclusion
Links to external resources

In a Geographical Information System (GIS) there are three main sorts of datas : alphanumerical, raster (bitmap pictures) and vector. A GIS should recover and mix this data to give information to users. First, information are displayed on screen with maps and data sheets and sometimes users need to print the map. In an online GIS, printings are most of the time managed by the browser printing system but in some cases, especially with wide formats, those systems are not efficient enough. A way to resolve this issue is to generate special printing files using external tools.

This case study will be the thread of this paper. First, we will see quickly how the initials data are inserted in the GIS database and how they are transmitted to the SVG viewer. Next we will focus on the SVG visualization and manipulation in a web browser, in this case IE with the Adobe plugin. Then we will look how to include raster (bitmap) files in the SVG and at last how to generate a PDF with the BATIK rasterizer. For each step, I will explain how it works and why we choose this system and not another. First things first, getting SVG.

As said before, many sorts of data can be inserted in GIS. Most common are vector files. Each "desktop" GIS (in opposition with "web" GIS) has his own vector format. Some of them became de facto standards (like Esri shape file or Mapinfo mifmid) that can be read in most GIS. In our case GIS data are included in a MYSQLdatabase using PHPscripts (previously composed of home made scripts and now of OGR tools). In MySQL, the storage format is Well Known Text (WKT). This allows a fast SVG generation, since WKT look a lot like SVG path definitions. The drawback is that WKT is very verbose. The workaround is to transform absolute coordinates of the WKT to relative SVG coordinates.

For example this WKT definiton :

POLYGON((12345 67890,12346 67890,12346 67889,12345 67889,12345 67890))

This definition represents a simple square that can be written like this in SVG :

<path d='M12345 67890 l 1 0 0 -1 -1 0 z'/>

Beside the "relativization" we can notice that the last couple of coordinates, which has to be the same as the first couple in WKT, is replaced by the z letter. This transformation is very easy to implement in PHP and brings a significant performance increase.

In the end, this SVG is compressed (SVGz) and sent to the web browser.

Once we have generated this SVG fragment, we have to display it. This will be done with the Adobe SVG Viewer linked with Internet Explorer. This goes back to our GIS early days. In 2004, one of the only way to do this was to use the "getURL" and "parseXML" provided by the Adobe SVG Viewer (ASV). Even if the "getURL" has since been replaced by Ajax functions, the principle remains the same today.

  1. Generating an URL that contains the description of the data we want to load.

  2. Send this URL with the "getURL" function.

  3. Parse the result in the SVG structure.

These operations are repeated each time the user moves the map view box or when he checks a layer to display it. In our case, ASV3 was a panacea : the couple getURL/parseXML responds exactly to what we need, ASV3 runs under IE which is available on the computers of more than 80% of our potential users. Plus it is free !

As we’ve seen, in a GIS you do not only display vector data, but also raster data. Rasters are pictures so the first idea was to simply use the "image" element. But in GIS, pictures can be very large "10000px*10000px" and their format are not recognized by SVG (tiff or ecw). Our first system was a sort of "thumbnail" generator which converted big pictures in JPG, sliced them into smaller ones and put the coordinates of each thumbnail into the database. This system was working but the performance were as bad on the thumbnail generation as on their displaying. We had to find something else...

The solution was to use Mapserver, n open source platform for publishing spatial data, and especially in our case, raster data. The principle is simple : you send to mapserver an url containing a viewbox and a reference to the data you want to get and it return a picture (or an an error message in worst cases...). The implementation of the principle is also easy : use an image element in SVG and give it a mapserver url as xlink:href.

Example of mapserver url :

<image x="0" y="0" width="13641" height="10294" id="image_mapserver_0" xlink:href="../../cgi-bin/mapserv?map=/var/www/actigis2009/data_client/1/mapserver/cplx/mapfiles/mapfileVilleDemo.map&layers=all&mapext=239573 259702 253214 269996&imgsize=860 649&mode=map" />

At this point our users has got vector and raster data loaded in the GIS. Now he also wants to produce a wide format printing of his map. One possibility is to generate a wide SVG in his browser. The drawback of this solution is that the user can't have a backup of his printing like a file that he can re-use later or transmit. So we decided to work on a solution to generate a file. This file format should accept vector and raster data. It also should be readable by all users. PDF was obviously the best choice. To achi eve this we will use 2 PHP libraries ( FPDFand FPDFI) and a Java tool : BATIK

The process is as follows :

  1. Send the text content of the SVG from the GIS to the server with the "printNode" function.

  2. Generate temporary pictures with the mapserver url (Batik does not like urls...).

  3. In the SVG text content, replace the mapserver urls by the temporary pictures one's and generate a temporary SVG file.

  4. Run Batik over the temporary SVG to get a PDF map.

  5. Create a new PDF template with FPDFI.

  6. Include the PDF map into the template.

  7. Delete temporary files and send the generated PDF to the browser.

But It is not as simple as it looks... We are dealing with large amounts of data and there are limitations and constraints we have to avoid like too big files to download or exceeding the capacity of the server. We are also often confronted to browser issues or SVG descriptions understood by ASV but not by Batik.

This case study shows that SVG is not only a standalone format. You can link it with many others tools in order to meet the needs of GIS users. Some links seem natural to me like the one between SVG and Javascript. The server side SVG generation is also very efficient (we could even say: brilliant) but I have concerns about the inclusion of raster pictures or about the final SVG rasterization. In SVG, V is for "Vector", we are not talking about SRG ! The "funny" thing is that semantic incompatibility was also felt during developments. We have experienced more problems with display or generation of the raster than we experienced with all other tools.

We put circles in squares and it is obviously not the best thing to do. Not the best thing, sure, but we had no choice but doing it. And we did it! With the help of open source communities, of major software editors and our own contribution, we managed to build a solid SVG based GIS used by hundreds of persons.