Vector Tiling in Marble Maps @Randa

Earlier today I returned from the KDE Sprint in Randa, where Torsten, Sanjiban, me and 50 other KDE developers met in the Swiss Alps for a week of hacking. Our Marble subgroup concentrated on vector tiling in Marble Maps. After some very productive days we have a first prototype of OpenStreetMap vector tile support ready both on the Desktop and on Android. It will become the new map rendering engine for Marble Maps on Android in future releases.

Our main goal for the Randa Sprint was getting the vector tiling tool chain running. This includes splitting OpenStreetMap data into smaller chunks and providing them on a KDE server (thanks, Ben). These chunks are then downloaded by Marble clients on the Desktop or Android and provide the data for the map you see. Fortunately we got the server infrastructure and a basic vector tile generation tool up and running within the first two days, and had it generate vector tiles for a couple of test regions for the rest of the week.

For texture tiles the server is responsible for rendering the map and client devices just display images. This approach is easy to implement for clients, but no changes to the look of the map are possible. Vector tiles require a client that is capable to render the data by itself. Even though that pushes more work on the client, it has a lot of advantages: The map always looks crisp and all elements can be adjusted dynamically. Some of that can be seen in direct comparison already as shown in this screenshot (best viewed in original size):


Marble has been able to render vector data since the very start, but support for OSM vector data only started to emerge recently. With a working tile server in place we now could concentrate on the fun part, extending and improving OSM vector rendering itself. Beaches, buildings with real height, glaciers, butchers, car sharing and narrow-gauge railways are just a few examples of elements we added to the rendering. There’s still a lot of further elements and details to consider, but we covered all major map features already.


The Randa Sprint brought us much closer to a releasable (end-user ready) version of vector tiling. Chances are good this happens within this year still. Our public beta version of Marble Maps in the Android Play Store will get the update automatically. You can become a beta tester if you’re interested in seeing it emerge. We now also have the weekly Marble Café where everybody is invited to get involved with Marble and learn about recent developments.

Last but not least I’d like to thank everyone who helped making the Randa Sprint possible, especially the awesome organization team around Mario and his family/friends as well as everyone who donated and supported it.

9 Replies to “Vector Tiling in Marble Maps @Randa”

  1. Really cool! The bitmap based solution has never looked crisp enough to me, and I’ve been looking forward to the vector map. Good to see the pieces coming together!

  2. Does this also affect the amount of data tranfer necessary for marble? I could imagine that downloading bitmaps (maybe even with different detail levels) creates more traffic than downloading some vector data once and render it depending on the zoom level.
    On the other hand I have no idea how large a OSM-data set is in general with all the metadata and POIs…

    Would be interesting to know

  3. @the_summer: Yes, vector tiles will be smaller. Downloading a couple of countries for offline usage should be fine when you have some free space.
    I have no estimate at the moment how small the data will become, because we will use a different file format and filter irrelevant data. Both will reduce the amount of data considerably. The current OSM data for the whole planet is 28.8 GB.

  4. Is it possible to download the OSM data (the whole 28.8 GB) and put it somewhere locally where Marble can make offline use of it?

  5. @Artur: Not directly, the data needs to be split into smaller files (tiles) first. Our server will do that and also offer region based bundles for offline usage in the future.

Comments are closed.