A real world comparison against Flash and ArcIMS
Abstract
The initial goal of this paper was to compare current examples of thematic mapping on the web for the 2009 elections in Germany. The national statistical institute offers both ArcIMS and Flash based mapping applications and the author of this paper examined the strengths of SVG in web mapping by building his own SVG based election atlas. While the subject area is similar – choropleth maps of Germany with comparable level of detail – the implementations differ a lot.
As such the emphasis of this paper is mostly on aspects of SVG with regards to mapping. It will discuss some of the features that were implemented in the SVG based map and will conclude with an outlook on how well SVG Web, the JavaScript library for rendering SVG in Flash, already works for web mapping.
Table of Contents
It is safe to assume that no one ever used Google Maps because of the cool Ajax technologies or Google Earth because of DirectX or OpenGL. People were hooked because those apps have an enormous appeal. As a consequence of this Google Earth might be shown off when marketing powerful graphic cards but it certainly isn’t a technology in search for good use cases. This is quite the opposite with SVG, a standard that took a good deal of optimism to use so far. Imagine you were to sell the Tesla car in areas where half the population doesn’t have access to electricity.
Thus in recent years using SVG involved an apologetic gesture. So much so that Andrew Emmons in his SVGopen 2008 keynote stated he was drawn to SVG with an underdog mentality similar to him being Canadian. Unlike SVG though, Canada has enlightened the world with heroes ranging from Pamela Anderson to Malcolm Gladwell.
But things are likely to change. In 2008 the browser market showed mature enough SVG implementations with Internet Explorer being the big exception. The latter is now being addressed by the SVG Web Project, that will render SVG through the Flash plugin for the time being.
While drafting this paper in the summer of 2009 the progress of SVG Web was so fundamental that the scope of the paper had to shift a little. For once you can render SVG through the Flash plugin it will be difficult to compare these technologies against each other. Also it doesn’t make much sense to spend too much time on the reasoning of past technological decisions when the landscape has changed this much.
The initial goal of this paper was to compare current examples of thematic mapping on the web for the 2009 elections in Germany. The national statistical institute offers both ArcIMS and Flash based mapping applications and the author of this paper examined the strengths of SVG in web mapping by building his own SVG based election atlas. While the subject area is similar – choropleth maps of Germany with comparable level of detail – the implementations differ a lot.
As such the emphasis of this paper is mostly on aspects of SVG with regards to mapping. It will discuss some of the features that were implemented in the SVG based map and will conclude with an outlook on how well SVG Web already works for web mapping.
In this paper the technologies are mentioned as a shorthand for the following three example maps:
The above linked websites are alltogether in German but you can have a look at this English language version of the SVG based election atlas in case you are interested in more detail. When examining those maps American and British readers may take into consideration that the german election system is mostly based on proportional representation.
Comparisons between Flash and SVG are done quite often and throwing a mapping server into the mix that spits out bitmaps might seem like comparing apples with oranges. One has to take into consideration however that there are government organizations in Germany who for several reasons believe in a very bare internet experience comprised of Internet Explorer without a Flash plugin.
The web mapping landscape has therefore seen Java applets and lately mapping server implementations, both ESRI’s ArcIMS as well as open source based solutions. The resulting apps typically offer basic map manipulation but cannot compete with the standard that Google Maps set, but at least those maps can be seen by any user.
When it comes to elections which are peak traffic events where there are 48hrs of very high demand, server based solutions don’t scale very well. Especially server solutions that are licensed by the number of CPUs aren’t very likely to be used in this scenario.
Because of this we haven’t seen any mapping server based solution for election results and the Federal Returning Officer decided to publish the official election results of 2009 in a Flash based atlas that was itself an adoption of what had been an SVG version in the 2005 election (ASV3 only).
While still believing in the superiority of SVG for interactive and data driven graphics I implemented an SVG based atlas on my personal website for the two country-wide elections in Germany in 2009. My intention was to see what was possible with current SVG capable browsers and I chose to not cater at all for users of Internet Explorer on my private website. The reasoning being that thematic mapping is a geeky enough topic that I wouldn’t expect the visitors to my website to use Internet Explorer anyway. Also Germany sees one of the highest market shares of Firefox in Europe and even on a website with a broader topic you would already see at least half of the users with non-IE browsers. This situation differs hugely even within Europe, a testament to which is that the UK Statistics authority recently converted their animated population pyramid to Flash as they still see a very high number of customers using IE.
Until the abstract submission deadline for SVGopen 2009 the aforementioned technology decisions against SVG were foremost driven by the lack of SVG support in Internet Explorer. There is only one other common argument against the use of SVG in web mapping and that revolves around copyright of shapefiles which can be better handled in a closed binary container that is Flash as in an open text based format. As the map of electoral districts in Germany is available under a free license as is all other data around the election the Internet Explorer issue is the last to remain.
Between the due dates of abstract and final paper the SVG Web Toolkit had seen the light of day and is already mature enough to be a game changer. Now that it is possible to render SVG with the Flash plugin in Internet Explorer and the remaining displaying discrepancies can be attributed mostly to bugs that are being ironed out quickly, the basic idea of this paper is blurring.
I have to be open about my bias here upfront. While I was looking honestly at the strengths of SVG I have also to admit that my knowledge of Flash is minimal and that I didn’t choose to develop with SVG after seriously considering a lot of alternatives.
It was the joy of trying things out in your text editor just like with the first steps into html, not worrying how to convince one’s IT department of a purchase decision for new software and so on.
On the other hand when it comes to vector drawings I grew up using Adobe Illustrator and am still struggling with Inkscape. Choosing software and standards has to do a lot with habits and the significance of the learning curve.
Lets see nevertheless why I never regretted the decision and what my argument for SVG in web mapping is.
-
Printing
It will come as a surprise to see printing of all things at the top of this list as the web is as far from printing as it could be. Nobody chooses a browser based on its printing capabilities and when it comes to SVG, printing an animation or a game just doesn’t make sense. However, mapping is different in many ways.
Everybody with a background in printing or graphic design will remember how in the age of the web one will be given logos or other artwork from a website and customers often don’t understand that those aren’t suitable for printing.
Very often the scalable in SVG or its resolution independence is just an effect that is shown off by magnifying some vector graphics compared to bitmaps. But even in 2009 screen resolution hasn’t evolved the same way that other properties of our computers have, and true resolution independence isn’t really necessary. Scaling bitmaps as is common with program icons in an operating system seems to strike a good enough balance between rendering quality and performance (except for KDE which uses SVG based icons).
On the other hand the breakthrough that were TrueType fonts was it’s quality in printing. With text we are taking resolution independence and high quality printing for granted, with graphics not so much.
Printouts from the web are mostly booking confirmations or boarding passes where even a pixelated graphic will help us remember which airline or which hotel chain the document refers to. But maps are different in that they have very detailed data, there may be text running along a river or a road and mostly that will be hard to read on printouts that originated from screen-resolution bitmaps.
Speaking of thematic maps, those are statistical graphics that are difficult to produce with the standard toolkit available to designers. While it will be easy to recreate a pie- or bar-chart with Illustrator from the raw data-points, thematic maps are in a different league. For a workflow in a newspaper it is very helpful for the journalists to examine data in a map, to select different variables, experimenting with various classification schemes and so on. If they can do this at their computers without becoming GIS specialists and then pass a PDF printout on to their prepress colleagues that’s a huge improvement. The SVG election atlas will be marketed to newspapers with the ability to produce print-quality maps.
Printing Capabilities of SVG rendering engines
Printing SVG from the web was always possible but for a long time this was limited to raster output. ASV3 offered the ability to control the resolution of the rasterized print output which allowed to tap into some advantages of SVG.
Safari 3 was the first browser being able to output SVG as vector-graphics to the printing interface and Firefox 3 seems to be even a little more accurate in this regard. Opera – the poster child for SVG standards compliance – still doesn’t print vectors from SVG in Version 10.
While it isn’t technically impossible to print vectors from Flash, the obvious way of doing this doesn’t usually result in vectors being printed. Experiments with the SVG Web Toolkit showed that the election map when rendered in Flash can be exported as vectors if one uses the Print dialogue of the Flash context menu. However only the content that is rendered with the Flash plugin is printed this way.
As mapping servers are by their nature delivering bitmaps to the client the only solution would be to generate a vector PDF on the server, a solution which however is mostly not available.
-
Progressive Loading
Another strength most of us wouldn’t notice anymore. With the SVG based election atlas described in this paper being 680k in its largest incarnation, the map is active after half a second on today’s broadband connections. It is nevertheless worth mentioning that the SVG format was specified with streaming in mind and on slower connections you can beautifully see how the map loads district after district of path data and immediately displaying it on screen as it has loaded. One can hardly think of a better load indicator.
-
Performance
As far as the three mapping projects described here are similar in the data that they are depicting, when comparing the performance one has to be fair in pointing out the differences: The ArcIMS as well as the Flash based map show the map of Germany with all the neighboring countries and coastlines whereas the SVG based map shows Germany as an island. Therefore the much more detailed cartographic data has to be taken into account.
On the other hand, the ArcIMS based atlas will cause traffic during almost any interaction. The Flash based atlas loads mapping data only once and then statistics for each topic as an XML file where the file-size of this data for one topic equals the complete data-set of the SVG atlas, which stores data in a JavaScript array.
In the Flash example every district is its own .swf file, whereas the ArcIMS based solution needs several files to build its user interface. The SVG map consists only of one file each for the map (including HTML UI), the data, and the program.
Table 1 shows some quantitative indicators of the first load experience of the three maps. In terms of file-size the SVG map could be reduced to half the size if GZip was available on the server whereas the Flash map profits from the compression inherent to the binary .swf file format.
\ requests kB sec ArcIMS 67 739 4.2 Flash 435 862 7.3 SVG 3 680 0.5 Table 1. Initial load of the mapping application
Interestingly the total file-size of all these different maps is roughly equal but the breakdown couldn’t be more different. It clearly shows why reducing the number of http requests is such a priority in performance optimization.
Given that the Flash map loads its data in uncompressed XML format and that its map is built from over 400 little building blocks the disadvantage of the Flash map with regard to the experience on first load cannot be attributed to the technology.
With regard to performance one can conclude that choropleth maps like the ones shown here have a level of detail (reasonable size) that they can be built into a single SVG map which then results in very high performance. For more detailed maps a vectorized version might be less favorable as you can see at OpenStreetMap.org where the browser gets served a bitmap and vector maps are only available as server generated export on request.
-
Searchability
When Steve Jobs demoed the system-wide search technology “Spotlight” that was introduced in the Tiger operating System (MacOSX 10.4) very often he would show a search for “Yosemite” and would reveal among the search results a PDF map in which the text Yosemite was highlighted. This was obviously a convincing demo although it wouldn’t come as a surprise that a graphics format that is based on text is likely to be indexed by a search engine. But this demo, that is still available on the apple.com website, is so compelling, as most people would regard a PDF of a map rather as an image and wouldn’t expect to find search results within an image. This kind of demo should be possible with SVG as well.
Unfortunately the gap between theory and implementation couldn’t be any wider. So far not only doesn’t the aforementioned Spotlight technology find text in SVG graphics, it is yet to be proven that a map based on SVG would be displayed in Google search results. Given the conference host of SVGopen 2009, indexing SVG content should at least get some attention.
Additionally the question is what type of searchable content would make sense to include in an SVG based map. As interactive choropleth maps go, most text is dynamically generated which poses additional challenges.
Finally while looking at the OpenStreetMap Project (OSM) that doesn’t have the copyright limitation and can offer vector output it comes at a surprise to not find text elements in an exported SVG from OSM. Text is rendered as vectors but only as individual glyphs and there is no semantically accessible text in it.
-
Coordinate Systems
It seems that SVG is a lot more developed when it comes to coordinate systems. Huge viewboxes that stem from shapefiles with real world coordinates (e.g. UTM) require equally scaled elements like strokes and Flash is limited for example to stroke-widths up to 255.
-
“View Source” goes well with democracy
The “View Source” advantage of SVG is not limited to maps and most developers owe at least some part of their craft from viewing source on other code. Given the topic of elections however the “view source” argument is more important than to please developers.
This section describes the unique features of the SVG based mapping application wahlatlas.net (german for election atlas).
Ever since Andreas Neumann published his Vienna map in 2002, the expectations of how an interactive choropleth map should look and behave were set. It was this use case that got me hooked on the technology when most other SVG examples of the time were quite lame.
In the meantime mapping on the web got popular thanks to Google Maps and it is safe to say that an interface expectation has emerged where one assumes that a map must be draggable and that the mousewheel is the interface to zooming. This is at least how I experience mapping and when I set out to building my SVG based election atlas it was one of the things I’d liked to implement.
By the second half of 2008 when I started working on the election atlas browsers with native SVG support were also able to mix SVG into XHTML and I had never liked to compose UI widgets in SVG. So the goal was to use SVG only for the map itself and for the histogram.
Statistical graphics are most convincing when they allow for interesting comparisons. A pie- or bar-chart allows comparisons in one data dimension as does one map, it shows how one variable varies in different regions. But data analysis shouldn’t stop here. Diagrams like the animated population pyramid or the gapminder/trendalyzer allow comparisons in more than one dimension where one of the dimensions is usually time which is depicted through animation.
Comparing regional patterns is a little trickier. A standard use case could be the question if people have more children in regions where conservative votes are higher. This would statistically be done by calculating correlations. However regression analysis is not for everybody. At least it would be nice to show two related patterns side by side and give people an idea what correlated variables would look like. The second use case is variation over time. Here election results are tricky in that changes in election results can be described in percentages or percentage-points, something that the media often confuses.
The shape of Germany makes it possible to have two maps side by side on a typical monitor and SVG with its roots in XML allows us to use the cloneNode method to clone the whole map with just two lines of code.
The subsequent challenge is to find a way to interact with these two maps on the same screen real estate. The idea here is to regard the right side of the map with classification key, histogram and the dropdown menus for selecting the topics as a floating control panel. This control panel can move from right to left to work on the map opposite of the control panel. Once the user is satisfied with his choices the control panel can be hidden.
In cartography generalization is know as a way of simplifying a map at certain zoom levels to offer a useful visual experience. With the SVG based election atlas this concept is applied to user interface elements. The consideration is that the map cannot be large enough and should use as much of the screen as possible. Interface elements however are displayed in the size the operating system deems sensible. Then when the atlas is used on smaller screens the interface elements on the control panel will simplify in that less significant elements submerge under others. In the case of the atlas the histogram will disappear when the browser window shrinks to a certain size.
The road to native SVG support in browsers was long and bumpy already but commitment to SMIL seems even worse.
When Apple introduced dashboard widgets in OSX 10.4 aka “Tiger” which were based on web technology, namely JavaScript and CSS, they had the need for smooth transitions to satisfy the Apple user experience. That’s the reason why Safari since version 3 supports CSS transitions. With the success of the iPhone people expect user interfaces that expose properties of physical movement, i.e. acceleration.
CSS 3 transitions are used in the movement of the control panel in two map view. Although they are currently only limited as a webkit-only extension their huge advantage lies in the way they degrade very well.
Unlike other JS Libraries (dojo.gfx, RaphelJS, jsxgraph) the beauty of SVG Web lies in its ability to run (almost) unaltered SVG markup, so converting was a matter of minutes. Most time (some hours) was spend on the CSS and JS peculiarities of IE that have nothing to do with SVG Web.
Given the tremendous pace at which SVG Web evolves it doesn’t make sense to list the remaining issues at the time of this writing. The election atlas is already mature enough to be deployed for Internet Explorer and the progress can be witnessed at