For quite some time, we've been exploring the direction we want to take with QtLocation. What are the key use cases? Which technologies and architectures make the most sense in the future? And how do we see our role — both as a project and as a company — within a broader system of servers, data sources, renderers, and applications?
We haven’t landed on a single definitive answer yet, but that’s part of the process. These are complex and interesting questions that open up a lot of potential and it is exciting to be part of it. And while location features might not be central to a general-purpose UI framework like Qt, they offer real opportunities to expand what Qt can deliver in modern applications.
A student projectWe got a first glimpse of what the future of QtLocation could look like through the bachelor thesis of three talented students from NTNU. The students implemented the Mapbox Vector Tile spec, which has been adopted by many map providers in one form or another, such as MapTiler, HERE, or ESRI. The students implemented the networking protocol and the decoder for the data and the stylesheet, as well as a software renderer based on our QPainter API. Besides being a great project for the students, it was also a fantastic opportunity to gain experience in vector map rendering and to validate our stack.
After the studentsAs a big map enthusiast, I couldn’t let this project die or rest. Almost a year has passed since the last update, and I think it's time for some news and feedback before we take the next steps. Over the past year, we focused on refactoring the protocol handling code and on porting it to QtQuick, the SceneGraph, and hardware rendering. Here is how the project looks right now, rendering the Oslo fjord region in the OpenStreetMap style.
We use the curve renderer to bring buildings, lakes, forests, borders, and streets into the SceneGraph as polygons and polylines. The curve renderer works like a charm, and its architecture fits well into the vector map pipeline. All the expensive operations happen when a new tile is received and processed by the curve renderer. In this step we can set all the layout properties (e.g., text position, fill patterns, allowed overlaps), and paint properties (e.g., colors, line width) are updated each frame through handlers returned by the curve renderer. Honestly, working with this API was a real pleasure, although it seemed intimidating at first. Give it a try if you need customized hardware accelerated 2D graphics!
That said, the curve renderer is a bit overkill for the kind of simple polygons and polylines that make up a map — it’s designed for Bézier curves, and that cost shows up in memory usage and processing time. At the same time, we’re missing some map-specific features like lines with a gap in the middle or a blur. We probably don’t want to burden the curve renderer with such domain-specific logic, but both issues could be addressed in a map-specific version.
The curve renderer is supplemented with texture nodes for icons and text nodes for labels. The Mapbox specification allows more text customization than QtQuick's text rendering API supports. For example, we’re missing features like a text outline of a specific width and optional blur. But these are things I could imagine being added to the Qt framework in the future. Another missing piece is text that follows a polyline — think street or river names. For now, we just draw the text tangential to the line. Still, this feels like something that could become part of Qt — maybe as a QSGCurvedTextNode?
Naturally, we support multiple layers (there’s a list of them shown to the right of the map), using multiple sources with varying resolutions and zoom levels. This includes raster layers, which are still useful in vector maps, such as a base layer for satellite imagery. We’ve built all of this with roughly 4,500 lines of code — a testament to how easy it is to get hardware-accelerated pixels on screen with Qt.
We are currently focused on the most important layout and paint properties, skipping many of the more nuanced features, 3D layers, and layer types for now. So yes, this is still very much a work in progress and clearly a proof of concept. But damn, it does a pretty good job of proving a point — at least in my (admittedly biased) opinion. I absolutely love this project.
The visionWith Qt’s recent push towards high quality vector graphics — through updates to the SVG module, the curve renderer, and the VectorImage item — I think a proper QVectorMap item would be a perfect fit.
The Mapbox spec is, in my opinion, an absolute piece of art (aside from a few remnants from the early days), and it is worth supporting. Its architecture would be significantly simpler than that of the current QtLocation Map with its plugin and Places API, as well as map items as an afterthought. With proper integration, we could make the map a first-class citizen in the Qt ecosystem and any Qt app on every platform. How great would that be!?
Creating a list of active layers (see the screenshots) was trivial, and I can easily imagine tighter integration with Qt styles, events, or even the Qt Design Studio. Adding QuickItems into the map should also be much easier and surely more efficient than it is right now. A 3D map based on QtQuick3D? Totally possible — and it would be a great addition to Qt. Adding Qt input handlers to catch taps on streets and buildings — no problem.
Of course, there are alternatives. MapLibre Native gives you a near-complete implementation of the Mapbox spec right out of the box, either as a standalone library or a plugin for QtLocation. But it doesn’t quite give me the same satisfying feeling as a fully native Qt implementation.
Up to now, this has mostly been a passion project — something I’ve pushed forward in my spare time, together with an intern who’s supported us over the last year. But the next steps probably require a more professional setup, along with interest and input from customers and users.
Would you like to see this come to Qt? How high a priority would it be for you? Is there anything we should know before moving forward? Let us know in the comments — and maybe we can make this vision a reality.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3