We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Maplibre-rs: Toward portable map renderers

00:00

Formal Metadata

Title
Maplibre-rs: Toward portable map renderers
Title of Series
Number of Parts
351
Author
Contributors
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Production Year2022

Content Metadata

Subject Area
Genre
Abstract
Map renderers play a crucial role in various applications deployed in Web, desktop, mobile, and embedded environments. For instance, we rely upon them to travel, commute, find the best hotels and restaurants, and locate our closed ones. More digital applications emerge in various areas, such as urban planning, transportation, or even pandemic monitoring, as they get adopted. Beyond digital environments, it is worth noting that maps also get printed in books, reports, or pieces of urban furniture. In this context, code portability, i.e., the ability to use the same codebase on various platforms, is a common problem. For instance, Mapbox and Maplibre both maintain a JavaScript codebase for the Web (e.g., maplibre-gl-js) and a C++ codebase for native platforms (e.g., maplibre-gl-native). These codebases enable their renderers to run in all major browsers (thanks to WebGL), in the main desktop and mobile environments, on servers (e.g., for headless rendering), and in cars, planes, or embedded settings. Guarantying that these renderers behave similarly and produce the same outputs on all these platforms is hard, costly, and slows down the ability of development teams to innovate and improve renderers. In this paper, we review the most popular map renderers from a portability point of view. We show that the existing codebases written in Javascript, C++, and Java fail at least in one area or another at producing a portable map renderer. Additionally, we present a state of the art for code portability, and we describe emerging standards and technologies that promise to enable truly portable and high-performance map renderers written in C++ or Rust to emerge. Among these emerging technologies, we find: - *Rust -* Rust is a high-level programming language designed for safety and high performance. The project started at Mozilla and is now developed by the Rust foundation. Its compiler targets native architecture, enabling it to compile applications for desktop (x86) and mobile (arm) environments. Additionally, the Rust compiler can target WebAssembly, a binary instruction format that can run on web browsers with near-native speeds. This not only enables Rust applications to run in native environment but also to be included as a library in Web applications. As a result, the same codebase can be used anywhere with only a few modifications. - *WebGPU -* WebGPU is a 3D low-level API that runs on top of DirectX, Metal, Vulkan or OpenGL depending on the platform and gives the developer access to the GPU. It is developed by the W3C GPU for the Web Community Group with engineers from Apple, Microsoft, Mozilla, Google, and others. It is considered the successor of WebGL version 2. Contrary to WebGL version 1 and WebGL version 2, which were solely designed for the Web, WebGPU implements a standard header file (webgpu.h) that makes it cross-platform. Based on the emerging technologies identified in the review, we study the feasibility of creating a truly portable map renderer. We present maplibre-rs, a proof-of-concept released under the terms of the Apache Software License, that can render vector tiles natively and in the browser. We describe its overall architecture and highlight some of the challenges encountered while devising a portable solution that transforms vector tiles into 2d and 3d objects. These challenges include: - *Rendering 2d vector tiles in a 3d environment -* The vector tile specification describes simple 2d objects encoded in grid coordinates, such as points, lines, polygons, multi-polygons, and polygons with holes. Several steps enable to convert these 2d objects into 3d objects that can be rendered in a scene, including: the conversion of grid coordinates into 3d scene coordinates; the tessellation of polygons to display surfaces in the 3d environment; the extrusion of buildings based on their number of storeys with an attribute stored in the vector tiles. - *Using WebGPU as a portable 3d rendering pipeline -* WebGPU exposes a wide variety of features to render 3d scenes. Among them, we explore: the rendering of the 3d objects with the WebGPU Shading Language (WGSL) based on styling rules and object attributes; The navigation within the 3d world with the camera, user inputs, rotation on 3 axes, levels of details and occlusion culling; The configuration of the graphic card, graphics API and more. - *Devising a portable network library -* Rust does not provide a network library that works both natively and in the browser. We created a uniform interface to download vector tiles to address this issue. This interface, based on the facade pattern, uses macros to select the proper implementation at compile-time depending on the targeted architecture. The native implementation relies on the HTTP package of the standard library. The WebAssembly implementation relies on Fetch API bindings. Finally, we present our future work and explore possible ameliorations. Overall, this review and feasibility study gives an exciting glimpse on a possible future for map renderers, where the same code can run natively and in a browser.
Keywords
Vector spaceSoftwareSoftware engineeringSoftware engineeringUniverse (mathematics)Portable communications deviceMappingMereologyBit error rateTexture mappingComputer animation
TelecommunicationSpacetimeTexture mappingUniverse (mathematics)Cartesian coordinate systemState of matterPresentation of a groupComputer animation
Physical systemAxonometric projectionRaster graphicsVector spaceTessellationTouchscreenReading (process)AbstractionCodeTime evolutionSoftware maintenanceAddress spaceSource codeElectric currentProof theoryComputing platformModemContext awarenessKey (cryptography)WordPortable communications deviceMappingGraphical user interfaceBefehlsprozessorArchitectureAndroid (robot)File formatoutputRule of inferenceExact sequenceJava appletOrganic computingDecision tree learningServer (computing)Dot productCore dumpRepository (publishing)Virtual machineSuite (music)Procedural programmingComputing platformOpen setDevice driverBuildingShape (magazine)Feasibility studyDemo (music)Matrix (mathematics)BlogMedical imagingGeometryTriangulation (psychology)CASE <Informatik>Square numberLine (geometry)Computer programmingPolygon meshShader <Informatik>Vertex (graph theory)Set (mathematics)TriangleResultantPolygonType theoryDifferent (Kate Ryan album)PixelZoom lensGraphics processing unitSystem programmingQR codeReal-time operating systemMikroarchitekturOperating systemWeb browserMultiplicationGraph coloringLevel (video gaming)TouchscreenAngleGoodness of fitVector spaceComputing platformWeb 2.0Feasibility studyTessellationProgramming languagePortable communications deviceWorld Wide Web ConsortiumGraph (mathematics)TesselationMilitary baseOpen sourceSoftware maintenanceSoftware developerImplementationStress (mechanics)CollaborationismAlgebraic varietyPower (physics)Forcing (mathematics)Texture mappingCross-platformCodeMultiplication signCartesian coordinate systemExterior algebraFrame problemLatent heatDevice driverDirection (geometry)Wireless LANThread (computing)Order (biology)Open setElement (mathematics)MetadataAndroid (robot)Computing platformProjective planeServer (computing)WindowRegular graphBuildingMatrix (mathematics)Block (periodic table)BefehlsprozessorSlide ruleoutputLibrary (computing)NP-hardSoftwareProper mapWritingParity (mathematics)Angular resolutionSoftware testingRaster graphicsBlogPhysical systemClassical physicsSoftware bugMappingComputer animationXML
Transcript: English(auto-generated)
Hi everyone, we are going to present our paper which is called Towards Portable Map Lenderers I forgot the first part, so it's Mapplib RS Towards Portable Map Lenderers So the team is composed of Maximilian Arman which is a software engineer from Germany and also the founder of Mapplib RS
Then we also have Jens Ingensan and Bertil Shapri which are two professors at the University of Applied Sciences of Western Switzerland also called the HEIGVD and then there's me and I also work at the university
So being able to travel the world in a seamless application was something quite groundbreaking in the 90s but since then it has evolved a lot and it's become something ubiquitous in our daily lives
So even if it has evolved a lot there is still a lot of improvement to be made and in this presentation we'll try to show you what we've tried to do to improve the state of the art but first I will quickly introduce how map rendering works
So we have tiling, so the world is really big and what we will do is we will split it into a grid of tiles and we will actually make multiple grids of tiles for the different zoom levels with different levels of details
and we have different kind of tiles, so we have the raster tile raster tile is basically an image and what we'll do is we will map this image onto the screen pixel by pixel but as it's an image if you zoom in it will get pixelated
on the other hand we have the vector tile So the vector is a geometry, for example this square is composed of four lines and the renderer will have to create an image from the geometry to display it on the screen So the steps to create this image is obviously first we will read the geometry
and then we will make a tessellation, a tessellation is also called triangulation in most cases the goal is to create a set of triangles from the polygon and this is required because the graphics APIs are optimized to work with triangles
Then the result of this tessellation can be called a mesh and we will give this mesh to the graphics API along with shaders A shader is a small program and in our case we use two one to decide where to put the vertices of the triangles
and another one to decide which color each pixel should be So why do we use vectors? So it's not only about scaling up and scaling down without losing quality there are other good benefits
So the main one is that we can dynamically change the styling So as we are rendering an image from a polygon we can just do a new rendering with different colors we can also change for example the language of the text we could show or hide different layers
Another benefit is that we can click on these geometries to show different metadata and also vector is usually lighter in size than the raster
The downside is that we have to do all this rendering and it will use a lot of GPU power especially if you want to render it in real time for example 60 frames per second So now let's talk about our paper
So we are focused on the portability of map rendering So what is portability? So portability is the ability for a code to run on any platform and a platform comprises many elements We have at the lowest level the CPU architecture
above that we have the operating systems such as Windows, Mac or Linux and then we have different graphics APIs such as OpenGL, DirectX, on Windows, Metal, usually on Mac and on top of that in some cases we will have an application
in which we will want to run our code and so that could be a web browser such as Chrome, Firefox or Safari and we will have to use different sets of APIs So what we have done is we have analyzed 37 map renderers
and we have analyzed their portability and we have come up with this graph So as you can see, we have many renderers which support PC, web and mobile but when you try to group them together for example mobile and PC are already less supported
and when it comes to web and PC or web and mobile there is almost nothing There is actually only one which supports web and PC and it uses similar technologies as we will present later
So the main takeaway is that none of the listed renderers is fully portable and the main issue is that is that companies or communities like Mapplib have to maintain different code bases and this is a big issue because it's almost double the work
you have to have two teams which do the development and they have to collaborate and so it's more costly and all of that will reduce the ability to innovate And so now Max will present to you Mapplib RS which is the map renderer written in Rust
which I'll let him present Thank you So Mapplib renderer is basically where portability meets performance
So first of all there are multiple Mapplib projects which you maybe know There is for example Mapplib GL Native, there is also Mapplib GL JS and now there is Mapplib RS and all of these are distinct So Mapplib GL Native is the previous implementation which runs on native
It's written in C++ and Mapplib GL JS is the implementation which currently runs or powers the browser So the Mapplib RS project started basically out as a hobby project last year After release it gained some traction
So Mapplib notice that it's complying to their goals And that way it started out as a playground for new technologies at Mapplibre which then led to this collaboration with joint forces with HEIG
and made this feasibility study additionally to this review And the future is still unclear which I will talk later about So all of this is made possible by WebGPU which is an upcoming W3C draft or specification
So it's a cross-platform 3D graphics API which you can use in a browser The cool thing is you can also use it on native, on desktop or on mobile because there is a corresponding implementation for it And it's basically the successor to WebGL
It's modern and portable like I just said And we kind of expect it to stabilize in 2024, 2026 At least that's roughly the timeframe which WebGL took to stabilize Could be way more, it could also be that it never happens, it will never come But we don't know, at least the specification is there and this is already a huge step
And we believe it will be the future So any WebGPU application is basically structured like this So you have an application on top You target it against the specification, the specification WebGPU And below that you're reaching all of those graphics APIs
For example Vulkan, Metal, DirectX, OpenGL and so on And below that you're eventually reaching the OS drivers and the graphics cards So why Rust? So it's written in Rust and the main reason for this is because Rust is a systems programming language alternative to C++
Basically we could also have been using C++ But C++ makes our development easier So Rust makes it easy to run a browser It makes multithreading easy And there's also an implementation available in Rust
Which targets or which implements WebGPU So this is just easing our development basically So in order to explain why WebGPU is so great I want to give a brief history So there's been a lot of graphics APIs over the past 20 years
Just for example OpenGL There's also WebGL which later came up And WebGL2, all of these are classical flavoured graphics APIs How we call them So all of them have roughly the same API And then there are the modern flavoured graphics APIs For example Apple's Metal, DirectX, Vulkan and WebGPU
And all of these have a different style of API And have a more modern style of API Which for example benefits mobile GPUs especially So with a portable map renderer
You basically have this goal of wanting to reach any device, any platform But there's a problem If you want to support any device Then you also have to support all of the graphics API Which you've just seen on the previous slide And WebGPU is basically the solution to that There are other ways to support all of these
But the difference is that WebGPU is basically designed to support all of these So it's a specification Which where portability is not an afterthought But it's the initial idea of the specification So that's how the map renderer looks right now As you can see text rendering is still missing because it's hard
I think everyone heard this maybe already once or twice But we already have some ideas how to do it And it will be like the next step And yeah that's Florence So we already solved quite a few challenges
So we have build automation for all of the platforms So iOS, Android, and the web And we package libraries for all of these targets So you can easily include it in your NPM project You can include it in your Swift project You can include it in your Android project Yeah, so we have as you've just seen
We have simple vector tile tessellation and styling We also, because we're multi-platform We're also supporting the servers of course So if your server has a GPU You can render tiles on the server If it doesn't have a GPU you can still render them But then it will fall back to the CPU
So we also have portable networking So networking works differently in a browser and a native In a browser we can use the browser APIs In a native we have our own stack And multi-threading works across all platforms as well So also in a browser and a native So what we're currently working on is raster tile support
We're working on glyph rendering and text shaping Which are two different challenges Equally difficult And we also have already extruded 3D buildings experimentally So in the far future we want to write SDKs for TypeScript, Android, iOS, Linux and Windows
So even though you can already include them There's no proper API in Kotlin and Swift So you have to write SDKs for all of these languages Which is quite a lot of work We also want to add more 3D features For example 3D elevation and also maybe support these roof shapes
And our extruded 3D buildings So in conclusion Portability was still an unsolved problem Or is still an unsolved problem And we can conclude basically that Map LibreRS is a new portable map renderer
And it solves the problem of portability quite nicely So for the future of Map LibreRS We basically have these two directions which we could go So there's on the one hand we might want to reach feature parity With other Map LibreRenderers For example Map Libre GL native or GL.js
But on the other hand we have the like contradictory goal Which would be to stay in experimental playground Test out new ideas Which then also could be implemented for example in native or GL.js So if you also love map rendering feel free to check out Matrix or Slack channels
We also have a demonstration available on GitHub Which unfortunately right now does not work on any Apple device Because Apple has a bug in Safari we are quite sure And there's also the blog with regular updates And feel free to grab the paper with the QR code
Thank you