Maplibre-rs: Toward portable map renderers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
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 | 10.5446/68944 (DOI) | |
Publisher | ||
Release Date | ||
Language | ||
Production Year | 2022 |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
| |
Keywords |
00:00
Vector spaceSoftwareSoftware engineeringSoftware engineeringUniverse (mathematics)Portable communications deviceMappingMereologyBit error rateTexture mappingComputer animation
00:43
TelecommunicationSpacetimeTexture mappingUniverse (mathematics)Cartesian coordinate systemState of matterPresentation of a groupComputer animation
01:24
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)
00:00
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
00:24
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
00:44
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
01:08
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
01:24
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
01:44
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
02:00
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
02:23
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
02:41
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
03:00
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
03:20
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
03:45
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
04:04
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
04:22
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
04:43
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
05:01
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
05:22
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
05:44
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
06:00
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
06:22
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
06:44
which I'll let him present Thank you So Mapplib renderer is basically where portability meets performance
07:06
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
07:24
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
07:41
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
08:00
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
08:22
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
08:40
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
09:02
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
09:22
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++
09:44
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
10:03
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
10:22
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
10:45
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
11:00
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
11:21
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
11:44
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
12:01
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
12:22
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
12:41
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
13:03
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
13:26
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
13:44
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
14:02
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
14:23
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
14:44
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
15:04
Thank you