 So, imagine being able to fly from outer space to any place on Earth. This idea was kind of groundbreaking in the 90s. There was no Google Maps, there was no Google Earth, but there was TerraVision. So TerraVision was basically the first kind of maps navigation system, which was fully digital. And so, at least for myself, when I first used Google Earth, when I was a child, it was quite cool. I think they even had some flight simulation in it. And yeah, it's pretty normal today, but it all started with TerraVision, which actually was developed in Germany at the start of the 90s. And it was the first virtual representation of the world. It was already networked. It allowed you to browse the world, all the satellite images of the world. And here on the right, you can see one, so you maybe know this person, he's also related to the CCC. And yeah, it all started in Germany. Sadly, the actual source code is not really available anymore, or I'm actually not sure I wasn't able to find it. So if you know TerraVision and you know how to run this, I would be happy to know about. So, short disclaimer about myself, I'm not really an expert in all of this. I just had a lot of free time. So I'm basically a software engineer, but I'm not really a geinformatics guy or graphic programming or even a Rust guy. I kind of just started to learn all of this with this project. So in the beginning, I want to talk about what actually a vector map is, and later I want to present Map Libre RS, which is this render I've been working on. So this is a vector map of Paris, and the cool thing about vector maps is that you have like a very smooth zooming experience. You notice from Google Maps, and it's very normal to have these maps today. And the thing about them is it's all rendered on a client. So you can actually style it on a client. So this is kind of the same data, but just styled differently on the client. So you don't have to prepare different data. You just style it differently, and you maybe also notice from car navigation where you dynamically switch from light mode to dark mode. On the other side, there's the roster tiles. And they have different benefits, but they feel sometimes a little bit clunky. So you don't have like a smooth zooming experience. You have very harsh levels, but they also have advantages. So on the one hand, vector tiles are very small. They're very space efficient. They allow this powerful customization. They offer this smooth zooming experience, but they require some hardware on the client end, which is kind of not a problem anymore today, because we all have pretty powerful smartphones. Raster tiles, yeah, you need them for satellite imagery. You cannot have like a very smooth experience with satellite images, as you would need infinitely many. They're very cheap on the client side. It's just images, but each tile is a little bit bigger. So still there's a lot of data, and we somehow need to manage this data. So the idea is that we break the world down into tiles. Each tile has a coordinate, and here I want to quickly explain how this is working. So basically we have on the left side a world. So this is just a data set with longitude, latitude, and we're projecting this onto some 2D surface. So right here you can see the world on zoom level was four, I think, or two. So the idea is that we are projecting it onto a 2D surface, and then we have different zoom levels. So on zoom level zero, we just have a single tile, which contains the world in a very reduced way. So we just have the reduced world. If we zoom now once into the world, we are reaching zoom layer one, where we have two to the power of one tiles in each x and y direction. And as you zoom in, you get more and more detail. And basically, yeah, it's getting a lot of tiles if you zoom in, but this is the way how we manage this amount of data. Each vector tile is basically just an SVG. So there are polygons, there are lines, polygons with holes, and that's basically what a vector tile is. And so I just said that it's basically an SVG, and how we can think about this is that we are having a pen, and we are drawing each tile by moving our pen. So for example, initially we move our pen to conducts one and two, and then we're starting to draw relatively to a previous location, so that way we kind of can just draw a polygon. And by doing the same in the opposite direction, we can cut a hole into polygons. So that's basically what a vector tile is. It's just a whole bunch of SVGs, layered on top of each other with some text and some further information for each feature. So that way we just have a single tile. So now to work on this data, we somehow have to send it to the GPU. And GPUs only work with triangles, so we somehow have to create a mesh out of this tile. There are fancy algorithms for this. In this example, I just drew it by hand. And yes, this term, originally, the term tessellation comes from Mosaic, so it's just a way to make triangles out of any geometric shapes, except circles. So we have a visualization pipeline in the renderer. We usually start off with some big data sets, for example, the OpenStreetMap data set, which is basically one file, and it's about 60 gigabytes if it's compressed. And in this preparation pipeline, which is not happening on a client but on a server, is we're producing very small tiles from this big data set. So that way we're creating a lot of files, so many files that they're actually no longer fitting on an ordinary file system. So suddenly you're reaching billions of files, which are all very small, such that it's easier to navigate them on a client. So what we're doing is we're creating then these meshes out of the tiles. We are maybe extracting some geodate information. We are building index indices where something is on the map, and we also extract, for example, text and metadata, and all of this data can then be uploaded to the GPU. And the thing now with this vector tile rendering is we have a map style, and this basically defines how we want to present this data. And so we basically have two inputs for a map on a high level. The cool thing about this concept is that we can combine multiple data sets. So, for example, if we have a data set about taxi stations and the OpenStreetMap data set, we can just layer them on top of each other defined by some style. So that's just a rough idea how rendering works. It's more or less the same probably on Google Maps. It's how all of the vector tile rendering libraries work nowadays. Now I want to present this project I've been working on. It's called Map Libre RS, and it's a portable map renderer which tries to be performant. So there are a few problems right now with map rendering. One of them is most map rendering libraries require multiple code bases in order to reach all the platforms. So usually there's one in TypeScript or JavaScript, and then there's one in C++. And this might be not a problem for a huge cooperation, but it's difficult to scale this in an open source project. And this is also one problem with which the map Libre organization currently is fighting with. Also licensing is sometimes quite a problem with map renderers. Some of them have been made proprietary. Previously they were open source. Map Libre RS is just licensed under MIT. And that's maybe my opinion. In my opinion the map rendering state of the art has not changed a lot in the recent years. There has been a lot of changes in around 2013, but in the previous years there hasn't been a lot of changes. All of this is made possible by a new web standard which is called WebGPU. You maybe know WebGL, and this will be the successor, which will hopefully be stabilized or released in the next five years. And WebGPU is a cross-platform 3D graphics API. It's quite modern compared to WebGL and it targets browsers, but it also works quite nicely on, for example, Android or iOS. So this WebGPU specification needs to be implemented somewhere. One implementation of it is called WGPU, which you can see at the center, which is a Rust library and it's possible to compile libraries which uses WGPU or projects which will choose WGPU to WebAssembly. That way we actually can reach quite a lot of different graphics APIs. For example, there is OpenGL, which is essential for Linux, and Android, for example, it also runs on iOS. There's Vulkan, which is especially known in Linux as well. There's WebGL, which is required in order to run in browsers. There's DirectX, which is very important for Windows support. And there's also Metal, which is essential to run on iOS and macOS. And there's a newcomer, which is WebGPU. So the architecture of the renderer is basically that we have the application at the top, which uses WGPU, and depending on the target we're trying to reach, so whether we want to reach a native application with run on your desktop or we want to reach a web app or a non-web application, which is, for example, Dino, it's a runtime for JavaScript comparable to Node.js, and we first select the target which we want to reach, and by doing that we are determining the way how we reach the low-level graphics APIs for each operating system. Sometimes we're going through a hardware abstraction layer, which is a little bit performance costly, but for example, if you're running in a modern browser or browser in three years, we can skip this hardware abstraction layer and directly go to WebGPU. So why Rust? It's not only because it's a great language, it's also because it's a systems programming language, and programming graphics basically requires a systems programming language. It's just much more convenient to program in a systems programming language. It also has outstanding support for web assembly, so it works quite nicely out of the box, and it already has support for atomic, shared memory, and multi-threading on a desktop, but also in a browser. So this is maybe something which would be quite difficult to achieve with C++ with Rust, it's just very easy. Also this major WebGPU implementation, WGPU is written in Rust, which brings us to our next question, why WebGPU? So as I already said, it's quite modern. It also allows to easily target the Metal API, which is something which is special. And with WebGPU, we easily reach Android, Linux, iOS, macOS, Windows, and the browser. Why is this a game changer? So this is my try to explain this. So there are kind of two different kinds of graphics APIs, one which I would call classical graphics APIs and low overhead ones. So at the beginning of 2000, there was OpenGL 2 already, which led to OpenGL ES, which eventually led to WebGL. So all of these share very similar concepts. If you're programming an app for OpenGL, it's quite easy to port it to WebGL or the other way around. In 2014, Metal was launched, which kind of introduced a new way to program graphics. DirectX 12 has a similar API, Vulkan has also a very similar API, and WebGPU kind of tries to unify these low overhead graphics APIs. WebGL 2, which is not that old, still follows this old way of programming graphics. So now if we are developing some new renderer, we want to be like, yeah, modern. We don't want to introduce technical depth in the beginning already. So I've drawn here three scenarios. So we are running MeB Libre RS against a low overhead graphics API, and below that there's Vulkan. That's basically the perfect way. Then we have a total modern stack. If we target as MeB Libre RS the slow overhead graphics API, but we're running on an old Android phone, there's only OpenGL, then it's still okay. Apple will deprecate this way, so it will be gone maybe in five years to reach OpenGL, but it's still okay. So the approach which is not that nice, in my opinion at least, is to say, okay, we're targeting this classical API, this classical way of programming graphics, and then we're running on a modern device which already supports Vulkan, then we're losing a lot of performance. So if we want to have a modern rendering stack, a future proof rendering stack, then it's, in my opinion, essential to target these low overhead graphics APIs. I want to give a quick demonstration if everything works. So this is running on macOS. This is the camp you're seeing, and it's still bare bones, so a lot of features are still missing. For example, text is missing, and basically a map without text is not worth much. But for example, you can already tilt, so it's 3D already without 3D buildings or mountains. Yes, but it works quite nicely, and it runs on all platforms. It runs smoothly at 60 FPS, also no browser with a single code base. Let's jump back. So while developing this, I also made a lot of mistakes. For example, usually Britain or Ireland is not in the middle of the Atlantic, but it's kind of funny to fix all of these problems, and it's very rewarding. So you might ask why not just use Google Maps or Azure Maps or Mapbox? You can use this, but you're getting quite locked in into a vendor. These libraries are proprietary. The licensing is sometimes quite difficult. It's usually provided as software as a service, so it's quite kind of difficult to use your own data. And of course, there are also privacy risks associated with it. So if you're using some American service or US service, then you also have to look into privacy laws. And so in my opinion, it's essential to invest in these free and open source rendering stacks. So a quick recommendation for a series. I already talked about television in the beginning. The billion dollar code is a series on Netflix, so there was a patent dispute between Google and television, and the series just explains what happens in a very emotional way, but it's definitely worth watching. So if you also love Maps, feel free to check out our project. There's a lot to do. We have a project without end. We have a Matrix channel. There's also a Slack where the Meplibre community hangs out more. And also feel free to just try out a web demonstration. If you're feeling adventurous, you can also try out a web GPU implementation, but that of course requires Firefox Nightly, and you have to set some special feature flags. So thank you. Thank you so much for your talk. Now, if we have any questions, please line up with these microphones in the middle. I don't know if there are any signal messages for us to start with. If not, no, okay. Do you have a question? Thank you. Well, first of all, thanks for your talk. Very insightful. More of a suggestion. You showed the map of the camp area. Did you know that there is a completely free vector tiles map at the Dutch Cadaster? So pdok.now has vector tiles with great details, street names, et cetera. All in vector tiles. So you can download the whole dataset, or you can use their server to access it. That's cool. Just from the camp area, you mean? No, the whole of the Netherlands. Ah, okay, yeah. Yeah, it's maybe also not that detailed because a lot of features are still missing. So, yeah. You're using OpenStreetMap? Yeah, that's OpenStreetMap data source, but they have something more detailed? More details, yeah. Cool. They're still completely open. Very cool. Thank you very much for sharing the detail. Any other questions from the group here? Well, if not, Max will be here after we wrap this talk. Feel free to talk further and get more details. So thank you very much.