Introduction

During the last six months, the Qt Group in Oslo hosted three students from NTNU in Gjøvik: Cecilia Bratlie, Eimen Oueslati, and Nils Petter Skalerud. Together, we worked on a proof of concept that might show us the direction to move forward with QtLocation. For the three students, this project served as their bachelor thesis, which they successfully defended last week in Gjøvik. We are very pleased to congratulate the students on their excellent work and to provide a short summary here for everyone interested in the potential future of QtLocation. 

QtLocation

QtLocation is our solution for including maps and geographical data in QtQuick applications. It started with Qt5 and was recently ported to Qt6. During its development, there were multiple data providers, each with its own (and sometimes closed) API to fetch data and render maps. In those days, we addressed this by making QtLocation plugin-driven, and every data provider (OpenStreetMap, ESRI, Here, Mapbox) provided or was provided with its own plugin.

Fast forward to the current date, and the digital map landscape looks quite different. First of all, rendering has become more challenging, and OpenGL is not universally available anymore (something we addressed with QRhi in Qt). Some data providers moved away from their open-source strategy, some lost relevance in the market, others switched APIs, and new players emerged. Additionally, some defacto standards have been established over the years. 

For QtLocation, this meant that only the OpenStreetMap plugin made it into the Qt6 port, although an unofficial MapLibre (formerly Mapbox) plugin is available. The OpenStreetMap plugin is compatible with all raster map services, where pre-rendered parts of the map, so called tiles, are sent from the server to the client. This approach has some severe drawbacks: zooming and rotating tiles lead to artifacts, text and line widths are not consistently sized, and they might appear upside down during rotation. In contrast, vector map services send the data as geographic coordinates and objects that can be rendered locally, allowing for precise adjustments to the zoom level, tilt, and rotation angle. This results in a much better experience for the user and a modern look. In short, raster maps cannot keep up with the high visual standards and expectations we have for Qt.

The Project

While there are many paths forward, the students wanted to evaluate the possibility of implementing vector map rendering themselves, relying only on the Qt framework. The advantages are clear: no dependencies (both license-wise and implementation-wise) and good integration into Qt, with the potential to use RHI and interact with parts of the map.

Server and API-wise, we chose to use the MapBox Vector Tile API, which has established itself in the field and is supported by various data providers (e.g., MapTiler). This API includes a JSON stylesheet that describes colors and other properties and a vector tile format based on Google Protocol Buffers that contains the actual data. Conveniently, Google Protocol Buffers have been recently added to Qt in form of the QtGrpc module and also Json documents are supported well.

The Mapbox standard is vast, and the students focused on the elements of a basic map, specifically basic-v2 from MapTiler. These elements include lines (streets, borders, rivers), polygons (terrain, buildings, lakes), text (normal text and text along paths) and symbols (however, which we didn't have time for). For simplicity, we limited ourselves to software rendering with QPainter.

The results are quite astonishing: In just six months, the students learned their way around the Qt Framework and implemented all the required networking, parsing, and rendering in a simple map application. The application allows panning and zooming (but not tilting and rotating). The map looks fresh, modern, and pixel-perfect at every zoom level. Text is always crisp and easily readable. Their implementation is hardly distinguishable from the reference implementation. As a side effect, we validated and tested our Protocol Buffer implementation which lead to some bug fixes and optimizations. You can have a look at the students' code in their GitHub repository.

We at the Qt Group learned a lot about vector map rendering and, in particular, the Mapbox standard through this project. The results show that a native implementation is achievable with Qt. It also gave us a peek into what is possible. We could easily provide APIs to modify the map contents, change colors to follow the application palette, or switch between dark and light modes. We could store and load data and stylesheets locally and have them interact with all other parts of Qt. In short, we could make the map a true part of the application.

Outlook

At the same time, many questions and problems remain to be solved. First of all, we require hardware rendering to make our implementation competitive and useful. Furthermore, we have to ask ourselves if we will ever achieve 100% compatibility with the standard or if that is even required and useful. Last but not least, there is usually a long way from a proof of concept to a productive Qt module.

Despite the challenges, we will continue with this project for at least the rest of the year. We will focus on hardware rendering, implementing missing features (e.g. symbols and fill patterns) and improving existing features (e.g. text rendering). In this context, we are very interested in feedback from our community and customers. Do you care about maps in your Qt applications? What are you using maps for, and which features are important to you? Do you agree with our selection of standards or do you have something else in mind? What should we try for the rest of the year? Please tell us in the comments or reach out to me.  

Last but not least, I would like to thank the students and the professors at NTNU in Gjøvik for the great collaboration. It was a pleasure to work with such talented and motivated people. The whole office is proud of you and wishes you the best for the future! We hope to see you all again very soon! If you are a student and wish to collaborate with us for a thesis project, don't hesitate to reach out to us.