Abstract
The purpose of this document is to highlight the links between SVG and open or free tools in an online GIS. A good way to do this is to use a complete case study. In this case, it will be the generation of a wide format printing. That requires recovering SVG from a database, SVG client side manipulations and transforming SVG to PDF
Table of Contents
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.
Why do not use a spatial geodatabase ?
In this domain it can seems natural to use a spatial database that can manage geographical data in binary format and provide spatial built-in function. But when our web GIS has been developed, tests demonstrated that spatial databases were less efficient in terms of access or writing than classical ones. Besides, the database had to be a free tool that excludes systems such as Oracle. Of course this choice prevents the use of spatial built-in functions like "union" or "intersect" but in our case faster SVG generation was more important than rarely used functions. At last, MySQL is well documented and includes a very large user community which facilitates the development .
Why PHP scripts ?
A LAMP architecture (Linux Apache MySQL PHP) is easy to set up and provides an ideal base for a web GIS. Then PHP offers many libraries that can be used outside the GIS system itself like picture generation with GD or pdf generation with FPDF. Once again the low cost of maintenance of such system is an important factor in the choice we made.
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.
Generating an URL that contains the description of the data we want to load.
Send this URL with the "getURL" function.
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 !
At this stage, we have a nice dynamically generated SVG displayed in our browser. Next step is to add interactivity to our SVG document. To do this we will use Javascript and the Document Object Model (DOM) of the generated SVG.
A menu on the left of the map allows users to change the style of the displayed layers. Through a simple interface, they can change the style attributes like fill/stroke-color, fill/stroke-opacity, stroke pattern... Each action calls a JS function which modify the DOM of the SVG.
In this case, the pointer-events attributes are used : onclick, onmouseover, onmousemove, onmouseout. Depending on what have been set, a layer could be interactive. For example, users can click on a layer to get information or have a tooltip on an overflown element.
Somewhere, ASV has been the trigger of the choice of SVG as the display system in our GIS. Free and functional, it was THE solution. Then comes the announcement of the viewer end of life. Fortunately, it continues to operate on IE7 and IE8 so we can still use it (even if a Flash "plan b" has been developed...). We are impatiently waiting for the IE9 beta release and hope that its SVG support will be sufficient.
A drawback (who was not one at the beginnings) is that ASV is only compatible with IE. More and more people are using other browsers and force them to use IE can cause us to lose customers.
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" />
The use of Mapserver has revolutionized our GIS. Even some vector data are now displayed with this system. In these cases SVG is only used to get interactivity on Mapserver pictures.
The dark side of this use of mapserver is that the GIS administrator has a different data structure to manage. With SVG, it has to use a homemade XML structure called "modele de vue". With Mapserver it also has to use a text based structure called "mapfile". A "modele de vue-mapfile" compatible editor should be a nice, useful and interesting project.
The bright side is once again the price of this solution.
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 :
Send the text content of the SVG from the GIS to the server with the "printNode" function.
Generate temporary pictures with the mapserver url (Batik does not like urls...).
In the SVG text content, replace the mapserver urls by the temporary pictures one's and generate a temporary SVG file.
Run Batik over the temporary SVG to get a PDF map.
Create a new PDF template with FPDFI.
Include the PDF map into the template.
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.
GIS : http://en.wikipedia.org/wiki/Geographic_information_system
PHP : http://www.php.net
MYSQL : http://www.mysql.com
ASV : http://www.adobe.com/svg
DOM : http://www.w3.org/DOM
Mapserver : http://mapserver.org
FPDF : http://www.fpdf.org/?lang=en