GSoC 2016, Marble

Hi everyone!

This post is an overdue introduction and past-midterm wrap-up for this year's Google Summer of Code, but that is a great opportunity to write about all the great stuff that happened during this past two months. 

Some of you may remember me from previous year, if not, check out my GSoC blog. I worked on the Vector rendering of Marble, which was really fun, but this year's project is the real deal. I've got to work for the Marble team under the KDE organization, on a project which's goal is to help create the long awaited Vector OSM map theme for Marble. With the help of Akshat Tandon and our two mentors, we look forward to bring Marble's real-time vector rendering powers to Android by the end of summer.

Instead of apologizing for the missed introductory and mid-term blog posts, I will just jump straight into the details of this exciting project. 

For those who don't know much about vector graphics, it stands for a type of computer graphics, where the image is rendered with the use of lines and polygons, instead of a pixel-matrix with limited size(raster graphics). Up until now, one of the mainly used map theme in Marble was the OpenStreetMap map theme, which uses raster images(256x256 .png files) from the openstreetmap website. While that is a pretty good and widely used map, it has its downsides, which all translates back to the nature of its raster-based rendering. Using the XML-like openstreetmap data, we can create a vector rendered copy of the same map, but with much more possibilities and functions.

I was invited to the KDE Randa Sprint meeting this year, and started to develop the osm-simplify tool as part of my GSoC project. This will be used to style, cut and optimize the vector data which in the end will be downloaded and rendered by the Marble app. Instead of .png raster images, the tile data will be stored in a compressed vector format(.o5m), specially created for the OSM data.

Difference between raster and vector rendered map in Marble, on Android
Source

osm-simplify tool

Reading, parsing the data

Thanks to the way how Marble is written to be used as a library for other projects, the parsing of the data takes only 3 lines of code, and we get the usual, KML based GeoDataDocument. 

MarbleModel model;

ParsingRunnerManager manager(model.pluginManager());

GeoDataDocument* map = manager.openFile(inputFileName, DocumentRole::MapDocument);

After creating a QApplication, you just need to include the marble header, and that three line of code will do the parsing in the most convenient and efficient way I could think of. 

Manipulating the data

In order to achieve an optimal performance, we need to use the tiling approach for the vector rendering too. That way we can limit the whole processing and rendering only to the visible part of the map. The data is split into several zoom levels, each zoom level containing more and more data. For example, at zoom level 1 we have only 4 tiles, which cover the whole world, but on higher zoom levels, ie. level 12 we have 4096 x 4096 tiles, that's more than 16 million tiles. The data in those tiles needs to be profiled to the zoom level in which they appear. On lower zoom levels it would contain only the country borders, and major lakes and rivers, but on the highest zoom levels, even buildings, trees, bus stops should be rendered.

I had to create the tool in a way to be scalable enough to handle the different data manipulations we throw at it. Calling it with various command line arguments, it can merge maps, filter ways, reduce the node count by joining them(which was added by Tandon), and finally cutting whole maps into tiles. In the coming weeks we will add even more functionality to it, in order to get the vector data profiled for our Vector OSM map theme. 

Some level 5 vector tiles loaded in Marble

In the previous weeks I was working on the tile cutting of the osm-simplify tool. This is considered by me the Gordian Knot of this whole project, because it has to manipulate each type of vector data the OSM map contains, from polygons, to lines, nodes, etc. It has many opporunity to introduce visual artifacts, so it needs to be as bug-free as possible. Currently I'm about to remove that annoying tile border-line issue, which you can see on the picture above.

A nicely cut tile would look like this, without any issues at the borders

Problems and solutions

I had some problems with relatively slow progress with my project during the past month, mainly because I hit too many walls, and didn't want to ask for help in a "I can handle this myself" spirit. After getting a slight earful from my mentors I realized that, and that communication is vital, in a project of this scale, so I guess after completing GSoC this year, that will be one of those things that will come to my mind when someone asks "what did you learn during GSoC 2016".

Speaking of which, I look forward to learn even more things while working with Marble during and after Google Summer of Code. Can't wait to use the Vector OSM map theme on my Android phone.

Have a nice day and summer,

David Kolozsvari