 And that one minute is up. I would like to introduce Tia Stage, one of the KD developers that I look up to. He's a guy I had the pleasure of giving an award to last real Academy. And as you can see, Volker has decided to not display it anywhere in his room as a way of being proud of it. So Volker, would you like to unmute yourself as an official introduction? OK, thank you, David. Yeah, hello, everyone. Three years ago at the Academy, I showed you KDI Generary, our digital travel assistance app. Last year, I talked about how we can use Vicky Data and OpenStreetMap in our applications. And this time, we are putting those two things together and going to look at indoor maps in KDI Generary. And that is the problem we are dealing with specifically. If you're looking on normal maps at complex buildings, like in this example, this is the Berlin Central Station, that consists of five relevant floors. Two of them have railway tracks. One of them has bus stops and tram lines. And three of them have shops and stuff. But if you look at that, it's all meshed together. You don't see any of that. But still, that building is large enough and complex enough that you would want a map to find your way around. So we need something better than that. And I mean, conceptually, that is fairly easy, right? We just split this into different floor levels and display them separately. And that will already get us like 90% there. And we have another important aspect to look at, and that is how you change between floors. That might sound simple at first. But if you think about traveling with heavy luggage or a stroller or with an injury or in a wheelchair, some of the usual ways to change floors like stairs are possibly an obstacle that is rather hard to overcome. So you want to know exactly what you're going to face in a large and complex building. Unlike with regular auto maps, unfortunately, this isn't something that you can just find as a ready to use component and integrate in your application. So we have to do the usual thing in that case, build it ourselves. So let's get started. The first thing we need is obviously the data. And OpenStreetMap is the obvious source for that. Luckily, their data model already considers the indoor scenario. And that is mainly done in two forms. There is the level tag that allows us to associate each element in OpenStreetMap with a floor level. And that is a fairly simple thing to do in OSM. And then there's the much more complex set of indoor tags which allows to model room-level details, walls, doors, pillars, whatever you might find there. That is a lot harder to edit. If we then look at what we find in practice in the OSM data, we notice that the indoor data doesn't have the same global high quality coverage that, for example, the street data has. We'll mainly find that in a number of showcase buildings. And fortunately for us, in a number of countries in a large amount of train stations. So specifically in France, Germany, Austria, and Switzerland, even smaller train stations have a sufficient level of detail. Airports, unfortunately, they are with a few exceptions done rather poorly on that so far at least. But the train stations is at least covering one of our major use cases in itinerary. So that's good enough to get started. The next step is we need to separate that data by floor levels. That's easy for elements that just exist on a single floor. But then we also have to consider things that connect floors like stairs and escalators. And that is unfortunately the level of floor level separation where most of the existing proof of concept indoor things based on top of OSM stop. But that doesn't produce what you would expect as a user. So we have to look at a number of additional things there. One such problem, for example, are stairs that have in the middle one or two smaller platforms. Those get assigned like floor 0.5 or 0.3. But that isn't something you want to see in a map, right? Some pseudo floors only containing tiny platforms that are completely useless. So we need to allocate that to the actual floor besides those and stack them in the right order. We have to deal with elevators that cause a large number of floors. We have to collect some information from other sources in OSM, for example, to have to be building how model correctly. But that still doesn't solve all the problems. If you remember the Berlin Central Station example from the beginning, that has five floors that matter to us and then there's a bunch of office floors on the top that aren't accessible to normal travelers so they are completely pointless. Immediately next to that station there's a number of high-rise buildings that contribute a number of extra floors. We also don't care about those. And underneath you might find service tunnels or water canals and stuff like that. So all of that we need to fill it out. So we end up with a number of rules and heuristics to actually get to the level separation that we want. That's an example of incomplete data. This is the main railway station in Brussels and you might look at that and consider it completely useless. You rather should look at that as an OSM contribution opportunity. Because fixing that is surprisingly easy. You just need a few small additions with setting the level tax to turn this from useless to something that we can actually work in. Adding extra text to existing elements in OSM is as easy as it gets in terms of OSM editing rights. You don't need to measure anything or create any new geometry. That makes it hopefully fairly quick to improve the data quality in the places where we need it. So now that we have covered the data aspect, we need to get things onto the screen. In terms of geometry primitives, this is actually fairly simple. We only have icons, labels, lines and polygons to consider. So QPainter can handle that out of the box. Label placement is another interesting thing to look at that requires remembering quite some geometry math. But that is a problem that also all the outdoor map implementations have so we can just follow it from there. There's some fun to be had with numeric stability as we are working with like centimeter resolution on a global scale. So it's very easy to run out of our space in mobile data types there. But the real complexity of the rendering is in the hundreds of rules that describe how specific things should look like in terms of fill and stroke patterns, in terms of stacking order and in terms of level of detail information. So at which zoom level you want to see them or hide them. Doing that in code is possible but rather annoying. Fortunately, better alternatives that allow us to specify this in a declarative way. One such thing is map CSS inspired by CSS cascading style sheets from the web. And just unlike there where we match against HTML DOM nodes, here we match against OSM elements. In this example, we are looking for railway tracks. And then as you know it from CSS, we can specify a number of attributes that define the visual appearance, like all the stroke and fill and outline things you might expect there. One interesting thing is how we can specify sizes there. So this can be done in screen pixels, which means it's a fixed size independent of the zoom level. Or it can be in physical dimensions. And that means physical dimensions in the real world. A railway track in Central Europe would usually be 1.435 meters wide. And then it keeps that with independent of the zoom level. Or as it's done here, we can reference existing tags in the OSM element where that information is already present. So we can just access that from the slide. And with that, we have an actually quite powerful system to define how things should look like on the map. All of that exists in the very creatively named KOSM neural map repository. As a C++ library that contains all the data processing and rendering code and neural components to integrate that easily in applications. For the data that uses the same backend server for OSM raw data tiles as well. That's something I briefly mentioned last year where we were still working on a new system for that while that has been deployed. And now has truly worldwide coverage and updates daily from the upstream OSM data. It might still take a record to until the changes have propagated through all the caching layers. But compared to what we had previously, this gives you very, very quick updates when fixing the data. We have the floor level separation I mentioned implemented in there. We have interfloor navigation, which means if you click on a stair or an escalator then you jump to the floor that connects to. If you click on an elevator, you can select which floor to go to. The MAP CSS engine in there is doing everything at runtime. There's no pre-compilation, which is very convenient for development. You can just life edit the style shade reload and immediately see your changes on the map. And it is very powerful for applications as well. As you can very easily customize the visual appearance. So you can hide stuff that is irrelevant for your use case or you can highlight things that you are currently working with or how we try to really customize that to the user preferences. And then we have built some things on top of that that I'm going to show you in a minute. I don't think we have the time for going deeper in the implementation, so I skip that part. And instead I'll show you some screenshots. So this is again Berlin Central Station, three of the five relevant floors. I mean, there's still a whole lot of stuff in there that isn't ideal due to issues in the styling, due to issues in the rendering and issues in the data. But this is a huge improvement over having everything meshed together. You can clearly see the railway platforms. You can see the stairs and escalators and elevators. You can identify the various shops and restaurants. This is actually useful to find your way around. And it's using the Breeze DAX styles. You will see some of the other screenshots using the light ones. That shows the flexibility in the styling we have. One note about performance. This image was actually an accident. I miscalculated some coordinates and ended up loading the entire city of Hamburg into this. Surprisingly, this loads within a few seconds on the workstation. But it doesn't really have 60 FPS rendering anymore. It's still somewhat usable. I just chose that there is more than enough room in there to run this on a building scale on a low-end smartphone. Let's get to some of the things that we built on top of the mapping data. I already mentioned that we identify escalators and elevators and stairs for interfloor navigation. Another thing that is particularly important for the itinerary use case is identifying airport gates and railway platforms. There are studies ultimately where we need to go based on our itinerary. Airport gates are very easy to handle. In the real world, they usually manifest as a door. OSM models them as a point. So there isn't much we need to look for or reassemble. Railway platforms are the total opposite. They can be several hundred meters in length and consist of an arbitrarily complex geometry for the platform itself. One or more tracks next to it which might be split in various sub-parts. The platform itself might be split in several sections. Depending on country and operators, there are different naming schemes for platforms and tracks, some of them internal, some of them publicly visible. We want, of course, the publicly visible ones. For more fun, for historic reasons, OSM has different tagging schemes for that. Data isn't always in a uniform format, so we need to find all those parts and puzzle them together somehow. The last part is opening hours. Itinerary knows when you are going to be at a railway station and for a long. If we know when the ticket shop or the coffee shop are open, we can highlight the ones that are open or hide the ones that aren't open while you are there, as there is no point to go in searching for coffee and finding the place close. Here are the pictures for that. On the left-hand side, we see a train connection in Cologne Central Station, I think. We are riding on track six marked in green. We are departing from track seven marked in red. Already that bit of highlighting adds value here. You immediately see that your connecting train departs from the same platform, just on the opposite side. Even if you have a very short connection, that should be easily doable. There is no problem with stairs or elevators involved. That way you can see that. On the right-hand side, we see different ways on how we make use of the opening hours. There is a screen line here, open for two more hours. We have the ticket shop selected there. That is a simple human-readable description of the current state. For a bigger picture, we have the table view. As I mentioned, we can also use that to gray out or hide elements on the map. Since that opening hours format of OSM is used in a number of other places as well, the whole code for that is in a separate library, and that contains both the evaluation engine for those expressions, as well as the building blocks for the user interface. That might be something of interest for Plasma Browser integration, for example, as websites or shops or restaurants contain that information often in a machine-readable way as well that this can consume. Then we have another thing added there, and that is additional data sources that we can integrate into the map. The first one is the operational status of elevators and escalators. That's something we get from accessibility cloud, which is a free software service that aggregates that from hundreds of different sources and provides a unified API for that. That's operated by the same people that do wheelmap.org, and they currently allow us to use this for this purpose as well. In the screenshot on the left, we see that in action, where we have two escalators that are operational and we have three elevators that are currently operational, all marked in green, and we have one elevator that is currently out of service. If you are relying on an elevator to change floor levels like that, that is, of course, a very crucial information. Knowing that building, or not knowing that building, you might expect you can just take the elevator next to it. That, however, will get you to different platforms. Depending on where you need to go, you might need to use the elevator on the right as an alternative. That is, of course, stuff you need to know somehow, and the indoor map provides you with that information. The other real-time data source we integrate is positions of rental bikes and e-scooters. If you use those to get to and from the station, it is, of course, good to know where they are placed and if there are some available at all. Here on the right, we see three rental bikes currently available at this parking space. That is the stuff we have implemented so far. That is basically just the map display. This is an indoor navigation. For navigation, we are missing two crucial parts still. One is localization, finding out where you are, and routing, finding out how you get from A to D. Localization is usually done with GPS outdoors, but that hardly ever works indoors. Even if it would, we still have the problem that we need to map altitude above sea level to floor level. Instead, indoor localization is usually done by measuring the signal strengths of Bluetooth and Wi-Fi beacons and then guessing based on that. That is probably something to look at rather on the plasma mobile system level rather than on an application level, as that needs somewhat low level access to the radio devices. It is something that is very hard to work on while you are stuck at home. That needs some time on site to actually make experiments and measurements. Not so far routing, that is something you could work on comfortably from your desk at home. Routing on the outside usually is done using graph algorithms, which we use the streets as a graph and then apply shortest path algorithms on that. Massively simplified, but that's the basic idea. With the indoor data, we have the problem that we don't have a complete graph of ways that connect every possible place we want to go. Instead, we also have areas where we just have a polygon describing an area on which you could walk. We need to mix those two data types and build a routing system that can handle those two. Of course, we need to consider the floor level changes specifically as well. That's an interesting problem to work on if you like geometry and graph problems. Then there's a few more things to look out for, I think. The thing that actually got this whole work started is I wanted to have the train coach positions properly displayed on the map. If you have a seat reservation in a train, that is the information you want in order to know where you have to go. Now we have the map. I can also ask the coach layout. The problem is bringing those two together as we are missing one crucial piece of information, namely in which direction the train needs to go on to the map. I hope that we'll eventually find a solution for that and then finally get that implemented as well. That, of course, is also a prerequisite for proper routing because we, of course, need to know where exactly we should end up in a train station to reach our train. Another thing to look into is generalizing that and using it for other building types. I have mainly focused on train stations and airports here for obvious reasons. You'll find very good indoor data also in museums, universities, or shopping malls, for example. There could be a value in creating a standalone indoor map for Plasma Mobile. We currently have a standalone app that is purely aimed at developing for testing and style sheet changes and so on. We might want to build something proper on top of that. Finally, there is the relation to Marble. Marble has all the auto-mapping done already and it has a ton more features than this has. On the other hand, we are missing the indoor mapping there and there's a few other interesting pieces in here that Marble might benefit from, like the geometry reassembly from the World Data Tiles. Marble doesn't do that yet. The Map CSS Engine or some of the performance work. I think we should at least explore how we can or if there's ways to share more of the work and the code between those two. I think that's it. Thank you for listening and are there any questions? Right now we have no questions, but people please do ask them. I shall ask some questions to Volker so he doesn't have a chance to relax. You've talked mostly about drawing a map and the actual rendering. Could you talk us through your workflow from a user from going from booking a ticket to using a map? How does it integrate from our K itinerary point of view? Sure. We don't have ticket booking integrated at this point, so you booked that on the Deutsche Bahn website or whatever the... Do you even have trains where you live? I don't know. As you booked a ticket on the render website, you get an email with a PDF containing that ticket. You're of course using K-Mail, so K-Mail recognizes that ticket and shows you what's in there in a compact form and offers you to add that to your calendar or the itinerary app directly. Then in the itinerary app, you have a timeline that contains your train trip or possibly multiple train trips, right, with your connections in between. And for the stations, itinerary offers you to look at the map. So if you want to know how complex your change is, if you need to change five floors or if it's on the next platform, you just open the map there and look at that. There is of course a lot of room there to integrate proper navigation once we have that, but right now it's basically just an option to open the map at the stations I'm going to travel to. In a second, I might be able to demo that. Oh, live demos, that's brave. We want to see it now. Yeah, I have that prepared for the map. I just need to look if I have an itinerary with demo data that I can show you. Okay, and if people do have questions, please do ask them. Your only chance, Olga might be gone from there after this on a big holiday using KI itinerary. And we will be able to find him. For that, we first need to implement the vaccination certificate as well, but that is ongoing. Let me see if this works. So this is a maybe slightly distorted KDI generally because I tried to scale it up so you have a chance to read it. And the card in here, that is the train ticket from Berlin to the pin meeting in Osnabrück. Just by clicking here, I get the station, the map already pre-selected on the platform I'm departing from. And it even has the arrival platform here. That is not for connecting trip that I booked, but it is for the public transport connection that itinerary recommended me to get to the station from home. And I can do the same at the arrival location. And again, it has the right platform already selected. And let me go back to Berlin. That is the slightly more complex station. So here I can just by clicking on the steps go down, navigate through the station, or take the elevator back up. We have one question from the chat, and a question from PureTrial is, do you have any plans to integrate with KDI Connect? And is it a matter of the situation where you can plan a route on the desktop and then do an actual navigation on your phone? We do have integration with KDI Connect. I mean, that's how came in, for example, since you were trying to check it to the phone. So that goes directly via KDI Connect as one of the options. What we don't have is that specifically for like route planning or anything like that. That is a good idea though. But I think the first thing we would need to think about as well is proper routing. Okay, now one more question. I've got two more questions. So the first question, how can we use anyone get this project? How can we run it? And what platforms? Oh, yeah, there is. I mean, this is a Kirigami application. Well, itinerary is a Kirigami application, right? And that has this integrated. That's available on any kind of Linux platforms. And it's available in the FDroid Nike build and release build repositories of KDI. And we are working on also getting into Google Play. And that gives me an opportunity to advertise the Android release talk I have on Friday, which deals with exactly how we get this properly deployed on Android. Okay, one more question to come in. And it is from Hudson. Would gamification fit into your project vision to encourage users to reduce their environmental impact? I mean, environmental impact is, I would certainly see in scope. We have a statistics... I don't think I'm presenting anymore. We have a statistics view that shows you like your CO2 emissions based on mode of transport and that kind of stuff. So there is... I mean, I can't, from the top of my head, come up with a good gamification idea to leverage that. But, yeah, I think I would see that definitely in scope. You have all your data so other people could then take out those libraries and build something else if you wanted to. I mean, we definitely try to collect the CO2 emissions wherever we have them. We have estimates based on mode of transport and distance to get it where we don't have them. I would like everyone to give Volker a big round of applause, obviously virtually, with your clapping emoji or otherwise. And I'm sure Volker will be around all week for questions. Exactly. If there's anything else you're interested in, just ping me on chat.