WEBVTT 00:00.000 --> 00:12.560 Okay, hello everyone, and welcome to my presentation about all of them to vote. 00:12.560 --> 00:18.920 The free D-Renderer for OpenStreetMap Data. 00:18.920 --> 00:23.880 OpenStreetMap does not need an introduction anymore, it's been featured in the maturity 00:23.880 --> 00:31.600 of talk in this room today, but because most people still interact with OpenStreetMap through 00:31.600 --> 00:38.480 a 2D map as a primary user interface, it might come as a surprise that OpenStreetMap is 00:38.480 --> 00:45.880 fully capable of all the power rings, 3D maps, and to do that, it needs a bit of software 00:45.880 --> 00:54.440 to actually convert this inherently to the data model into 3D models, and OpenStreetMap is 00:54.440 --> 01:01.440 exactly a piece of software that can do that for you. 01:01.440 --> 01:06.880 To figure out what OpenStreetMap does exactly, I think it's a good idea to start with 01:06.880 --> 01:09.800 the input side. 01:09.800 --> 01:15.800 On the input, we are using OpenStreetMap data, and I'm using buildings as an example 01:15.800 --> 01:22.440 to explain how exactly that works, because if you are familiar with the OpenStreetMap data model, 01:22.440 --> 01:30.160 you will also know that the geometry in OpenStreetMap is really just 2D points and 2D lines, 01:30.160 --> 01:35.280 and there's not really any 3D geometry in their natively. 01:35.280 --> 01:42.320 Instead, the 3D part comes in with tags, with attributes that are added to the geometry, 01:42.360 --> 01:48.320 which may add information such as a building side, a building's number of levels, and 01:48.320 --> 01:51.320 that's where the set dimension comes in. 01:51.320 --> 01:56.480 This also means that to actually get a 3D model out of this, you need software that 01:56.480 --> 02:00.320 understands all these different tags that can be applied. 02:00.320 --> 02:05.320 For buildings, or parts of buildings, this might also include the building's color, 02:05.320 --> 02:13.680 the building's material, or the shape of the roof, taken from a catalogue of common roof shapes, 02:13.680 --> 02:19.720 and putting that all together, let's get some pretty recognized the building shapes 02:19.720 --> 02:24.560 despite OpenStreetMap's 2D data model. 02:24.560 --> 02:29.680 The same logic applies to pretty much everything else that's in OpenStreetMap. 02:29.680 --> 02:35.760 That includes simple indoor tagging to represent the inside of buildings. 02:35.760 --> 02:41.120 But also, for example, roads and hundreds of other types of objects, some of which people 02:41.120 --> 02:47.560 added with the intention of having them shown on a 3D map, but most of which were just 02:47.560 --> 02:53.920 added for other reasons, but can never the last be used to improve the visual appearance 02:53.920 --> 03:00.280 of a 3D scene remarkably. 03:00.280 --> 03:06.360 When we talk about adding OpenStreetMap data to it, there are many different ways of storing 03:06.360 --> 03:12.760 and transmitting OpenStreetMap data, and OTHM to work supports a pretty large subset of those, 03:12.760 --> 03:19.800 and for different use cases, you might want to prefer different methods. 03:19.800 --> 03:26.120 And just to be clear, when I say I'm using OpenStreetMap data, that means data in the OpenStreetMap 03:26.120 --> 03:27.520 data format. 03:27.520 --> 03:32.800 If you want to render, for example, historical data, or even fictional data for some 03:32.800 --> 03:37.720 fantasy cities that you just made up, you can also do that as long as your stores that data 03:37.720 --> 03:44.120 in the OpenStreetMap data format and then feed that into OTHM to work together 3D model. 03:44.120 --> 03:50.360 Okay, let's move on to the output side. 03:50.360 --> 03:57.960 The output consists of 3D models, but 3D models are again stored in a large number of 03:57.960 --> 04:04.360 formats, of which OTHM to work supports individual model files in OBJ and GLTF format. 04:04.360 --> 04:11.400 Image is rendered from the 3D models, 3D types, more on that later, and interactive scenes. 04:12.200 --> 04:19.080 First, let's talk a bit about GTF, because that's really the format you should choose if you 04:19.080 --> 04:26.680 don't have any specific preference, because it supports larger subset of features from OTHM 04:26.680 --> 04:34.200 to work, that is most of OTHM to work can do, will support, will be supported by an expert 04:34.200 --> 04:35.560 to cheer it up. 04:35.560 --> 04:41.400 It's an open standard for 3D models and tons of engines and editing tools into 3D 04:41.400 --> 04:47.640 ecosystem supported, so if you want to have your OTHM 3D models in Blender, for example, 04:47.640 --> 04:52.520 that's easily possible by just exporting FGTF and importing into Blender. 04:54.920 --> 05:00.760 When working with GTF, OTHM's words have a few nice features such as support for binary 05:00.840 --> 05:07.400 GTF or compressed output, the choice to have a single file containing everything that needed 05:07.400 --> 05:15.320 for the 3D model or showing texture separately, and the option to have various kind of post 05:15.320 --> 05:17.560 processing steps applied to your 3D model. 05:21.800 --> 05:25.960 One use case for GTF export is to have 3D tiles. 05:26.840 --> 05:31.720 That's when you want to have 3D model of an area that's too large to store everything in a 05:31.720 --> 05:38.840 single file, and the most popular way to address that problem is to have a regular grid where you 05:38.840 --> 05:47.560 slice, you're seeing into a square-like shapes that can be posted together to form a larger area. 05:48.280 --> 05:53.320 And OTHM provides easily generate them for you, just gives the bounding box or set of bounding 05:53.320 --> 05:56.840 boxes you want 3D tile for, and it will generate them all. 05:59.240 --> 06:04.920 The most popular standard for 3D tiles is the 3D tiles standard, and again OTHM to 06:04.920 --> 06:12.360 write supports the necessary extra files in addition to the model to make it compatible with 06:12.360 --> 06:18.920 that standard with the current exception of not supporting the more modern feature of implicit 06:18.920 --> 06:22.440 per wood tiles yet, but that's a work in progress at the moment. 06:23.880 --> 06:30.280 If you want to try out those 3D tiles, there is a demo for some countries, unfortunately 06:30.280 --> 06:35.320 in charge of Germany or Switzerland at the moment, available on the OTHM to work at website, 06:36.040 --> 06:41.240 but I would recommend doing that with a laptop or desktop computer because I haven't put much 06:41.240 --> 06:43.240 effort into tuning in from OTHM yet. 06:43.400 --> 06:51.240 Okay, after input and output, let's look at how we actually use OTHM to work, because there's 06:51.240 --> 06:57.400 more than one way to do so. Specifically, there are several ways that we will now look at one by one. 06:58.840 --> 07:04.840 The first is to have a 3D tile server. That's like with the examples that I mentioned before, 07:04.840 --> 07:09.880 the demos that featured on the website, you have a server that calculates the 3D models, 07:09.960 --> 07:16.680 and you have one or many clients which download these models in order to show a 3D world. 07:16.680 --> 07:22.760 This means the calculation, the conversion from OTHM streetmap data to models happens on the server, 07:22.760 --> 07:29.800 but surrendering, so you think some real-time acceleration in graphics hardware happens on the client machine. 07:32.040 --> 07:37.400 You can, however, also run OTHM to very detail locally or on your own server, 07:38.120 --> 07:43.720 and if you want to do that in a way that can be scripted, you might want to use the command line interface. 07:45.480 --> 07:51.080 The command line interface exposes most functionality of OTHM to world, and it uses some sense of 07:51.080 --> 07:58.040 default so that, for example, if you want to convert some OTHM data to an image or a single 3D model, 07:58.760 --> 08:04.120 that only takes an input and output parameter for the converts up command, but of course, 08:04.120 --> 08:10.680 if you want to, you can also control all sorts of things such as a camera angle by adding additional 08:10.680 --> 08:19.320 parameters to that command. Command-line scripting works across many platforms, but 08:20.680 --> 08:28.920 if you are using OTHM to world on a machine that has travel support, you could also use it 08:29.000 --> 08:36.040 as a software library directly in some software running on the JVM, by using the 08:36.040 --> 08:42.040 name or gradal packages that are available for the purpose, and which are documented on that URL. 08:43.880 --> 08:50.600 I am currently 95% complete to also offer a library interface for 08:51.480 --> 08:57.400 JavaScript running entirely in the browser, so at that point, you will be able to do the conversion 08:57.400 --> 09:03.960 from OTHM data to 3D model entirely in a browser client and will no longer need any server 09:03.960 --> 09:11.480 if you don't want to. That's also a desktop client, which is a pretty old feature of OTHM 09:11.480 --> 09:18.680 for world. It's useful if you prefer having a graphical interface over using a command line interface, 09:18.680 --> 09:23.800 and it's also very useful if you are editing open street map data locally, for example, 09:23.800 --> 09:29.480 this chosen or a similar editor, and want to have a preview before you upload the data to the server. 09:31.320 --> 09:38.520 But for this particular use case, I am also currently working on editor integrations, 09:38.520 --> 09:44.200 which essentially gives you a 3D preview directly in your open street map editor. 09:45.240 --> 09:52.360 This example is using a modified version of the urban i3D plug in with an OTHM to world back end, 09:53.320 --> 09:59.320 but I am also working on potential integration for other open street map editors to make it 09:59.320 --> 10:04.760 as easy as possible for a large subset of the OTHM community to contribute 3D data. 10:06.920 --> 10:11.960 This work on editor integrations is currently being supported by the prototype fund, 10:11.960 --> 10:17.480 which is an open source support initiative by the German Federal Ministry of Research, Technology, 10:17.480 --> 10:22.520 and Space, so let me say thank you for funding me to work on that. 10:25.480 --> 10:33.400 Okay, so we've looked at the input output and user interface, so as a final part of this presentation, 10:33.400 --> 10:39.640 I would like to take the opportunity to look more closely at a few of the steps that happen 10:39.640 --> 10:46.280 in between the input and output. So what kind of things does OTHM provide actually have to do in order 10:46.280 --> 10:55.800 to produce those 3D models? The first one is to look a bit at AFF, which in my writing here includes 10:55.800 --> 11:05.240 tech-driven models. Tech-chairs are present in pretty much every 3D model, and as a use of OTHM 11:05.240 --> 11:10.600 to world, you don't really have to bring your own OTHM to world shifts with a large collection of 11:10.600 --> 11:17.160 tech-chairs and a default style that you really only need to edit if you want to have your own look, 11:17.160 --> 11:22.600 otherwise it can just use a default tech-chairs. It has tech-chairs that are after images, 11:22.600 --> 11:29.880 back to images as well as some that are generated at program runtime. For example, text on traffic 11:29.880 --> 11:37.480 signs will only be generated at runtime in order to not need a single tech-chairs file on your 11:37.560 --> 11:42.520 computer for every potential tech that might appear on a traffic sign somewhere in the world, 11:42.520 --> 11:47.080 so it just generates the tech on that particular sign value runs program. 11:49.640 --> 11:53.880 It's a port tech-chairs not just for the color of the object, which is the most common type of 11:53.880 --> 11:59.240 common tech-chairs, but also for all the other types of tech-chairs which are used with 11:59.240 --> 12:03.880 physically-based rendering. If you don't know physically-based rendering, that's not a problem, 12:03.880 --> 12:09.960 but it's a common way to essentially simulate the interaction of light with 3D models in 12:09.960 --> 12:17.320 modern graphics engines, and it's also supported by the GTF standard, so to make full use of those 12:17.320 --> 12:23.560 abilities, OTHM to world, also support these other types of tech-chairs, which describe a 12:23.560 --> 12:29.720 material properties, other than just the color of the material for a more realistic visual appearance. 12:30.120 --> 12:37.240 For performance reasons, it combines some of these into a single tech-chairs, so that you don't 12:37.240 --> 12:47.880 have that many of them. For some features, it's not easy to find readily available tech-chairs 12:47.880 --> 12:52.680 on the internet somewhere and not everyone is a graphic designer, so OTHM to world also has the 12:52.680 --> 12:58.760 ability to generate those tech-chairs from geometry automatically by just placing a virtual camera 12:58.840 --> 13:08.280 in front of the object and creating the texture. Because some engines do better with a small number 13:08.280 --> 13:13.640 of large tech-chairs on the other way around, OTHM to world can, optionally, all the combined 13:13.640 --> 13:23.560 many tech-chairs into a few larger ones with a so-called tech-chairs at last. It's case tech-chairs, 13:23.560 --> 13:29.640 so that they fit neatly onto geometry, and yet that brings us at the end of the part about 13:29.640 --> 13:37.720 tech-chairs, and then to before us, that assets also include 3D models. So for the most part, OTHM 13:37.720 --> 13:46.440 to world create the 3D models during one time from OTHM street map data. But some kind of features 13:46.440 --> 13:52.120 you might actually rather want to model by hand or download from some side, for example, 13:52.200 --> 13:58.760 in the scene the car models are obviously not from open street map. It's not updated that often 13:58.760 --> 14:05.160 that we move a note every time someone moves a car, so instead those assets randomly placed, 14:05.160 --> 14:13.640 and we can supply models of cars through the map style and randomly values a color as well. 14:14.200 --> 14:22.200 But the external models don't just allow us to show these kind of generic models such as cars. 14:23.480 --> 14:31.960 They also allow us to fetch models from the 3D model repository, which is another open data 14:31.960 --> 14:39.640 project which allows us to have 3D models shared by users and linked with OTHM street map. 14:40.600 --> 14:49.320 One potential use case is landmarks, such as the iFitower. OTHM does allow mapping 3D buildings 14:49.320 --> 14:54.920 to some extent, but there's a limit to the level of detail you can express with just notes and 14:54.920 --> 15:01.400 ways. So when you go beyond that limit, you can use 3D models and OTHM towards we place them 15:01.400 --> 15:09.960 in the right location in your 3D world. The second feature spotlight is much shorter, 15:09.960 --> 15:15.400 but I wanted to have a quick look at real-time performance and level of detail. 15:17.240 --> 15:25.960 So OTHM's world does also details that add some extra bits to a scene such as like ballads, 15:26.040 --> 15:32.120 traffic signs, bicycle packings, then lots of more details that have a significant 15:32.120 --> 15:38.360 performance cost if you have too many of them. So the usual trick to give us that is to have 15:38.360 --> 15:43.800 a high level of detail for areas close to the camera and a low level of detail for everything else. 15:44.520 --> 15:50.520 And to enable that technique, OTHM toward can export a scene at different levels of detail, 15:50.520 --> 15:52.440 depending on what the user asks for. 15:55.960 --> 16:02.920 And finally, something I also find interesting, the way OTHM towards deals with objects that 16:02.920 --> 16:09.880 are connected to each other. Often in open street map, you have things that are just 16:09.880 --> 16:14.280 discrete objects. So there's one point that represents a weight bar of kit, 16:14.280 --> 16:20.440 another point that represents a street lamp. And so they are entirely distinct objects. 16:20.760 --> 16:26.280 But in the real world, sometimes you have a weight bar's kit that attach to the street lamp. 16:27.000 --> 16:33.960 And you can describe that fact in open street map. And if someone describes it in open street 16:33.960 --> 16:39.880 map, I also want to support that information in OTHM toward. So the weight work is, 16:39.880 --> 16:46.040 I have so so called attachment connectors, which is just a point in this case on the weight bar's kit, 16:46.200 --> 16:53.320 that wants to connect to some other object nearby. And if it finds an object of a suitable type, 16:54.600 --> 17:00.840 the attached object is just moved and rotated such that it fits smoothly onto the other object. 17:02.040 --> 17:07.880 And you get the appearance of a seamless model despite the fact that open street map had two 17:07.880 --> 17:14.680 separate notes next to each other. This can be used for many other things too. 17:14.760 --> 17:18.120 Like for example, there's a traffic sign attached to the street lamp as well. 17:19.480 --> 17:25.640 Maybe there are solar panels attached to the roof of a building. Maybe there's a rooftop parking 17:25.640 --> 17:32.280 on top of the building. Maybe there are objects such as billboards attached to a building's voice. 17:33.080 --> 17:39.880 Maybe there are objects such as tables inside a building that are placed on top of the 17:39.880 --> 17:44.840 earth, a second or third floor of the building. Maybe there are objects on the bridge and 17:44.840 --> 17:50.040 object below a bridge. And you want to object above the bridge to attach to the bridge so that 17:50.040 --> 17:55.880 there are higher absence of one's below it. And many things like that can all be described with 17:55.880 --> 18:03.080 this attachment connector concept. Again, with the goal to make the mode out of open street map data, 18:03.080 --> 18:09.880 when converting it to speedy models. Yes, that brings us to the end of my presentation. 18:10.680 --> 18:14.440 Please have a look at Oatham to Verge. And if you have any questions, 18:14.440 --> 18:21.480 either of them right away or get in touch with me at the conference or through digital context channel. 18:22.200 --> 18:24.600 Thank you for attention and looking forward to your questions. 18:24.680 --> 18:43.160 Hello, thank you for your presentation. I have a question regarding the library you use and 18:43.240 --> 18:55.160 the sense that you choose to use a barbell on that yes for the ring. Why you choose to use this? 18:55.160 --> 19:03.720 Why not to use 3GS directly? I'm not sure. Why did you use Babylon JS? 19:04.680 --> 19:06.680 Is that the 3GS? 19:09.400 --> 19:15.640 So, they would both work pretty much equally well for that use case. I mean, I already have ready 19:15.640 --> 19:22.200 made 2GF models and both are able to load 2GF objects and play them in a scene. It's really 19:22.200 --> 19:27.160 out of just a few hundred lines of charge script, most of which is boilerplate, though it was 19:27.160 --> 19:33.160 down to personal preference. It works with both of them and, yeah, if you want to use 3GF to 19:33.160 --> 19:35.960 end the Oatham to Verge model, that works perfectly fine of them. 19:42.440 --> 19:51.640 I'm yes. So, Oatham to Verge output GATF5 and that youth case and for GATF load up for 3GF, 19:51.640 --> 19:59.320 I feel that you feel it compatible. Thank you so much for the talk. What is your kind of policy 19:59.320 --> 20:05.640 on porting to other programming languages so that they can take advantage in the same way 20:05.640 --> 20:11.480 of the library elements? Like you said your point in porting to JavaScript is their opportunity 20:11.480 --> 20:17.480 like port to Python or GoLang to be able to provide the same OSM to 3D model conversion. 20:17.800 --> 20:26.520 So, so far, I've only done it if I could have a single code base that is automatically converted 20:26.520 --> 20:36.040 to other platform. In the JavaScript case, that works through TVM, which is a Java to JavaScript 20:36.040 --> 20:45.240 or web assembly compiler. So, essentially, I want to avoid the situation where the port would 20:45.320 --> 20:50.200 diverge. I've got your free to port it yourself, but in that case, it would then be more like a 20:50.200 --> 20:55.000 fork. Yeah, it's going to ask would you be open to me or someone else porting to a different 20:55.000 --> 21:03.080 programming language? So, I'm trying, I've also have the goal of supporting at least Android 21:03.080 --> 21:11.800 of value, which should be relatively easy. Python is probably harder, essentially an external 21:11.880 --> 21:18.520 or native dependency. And then my other question, when you said about the models connecting to one 21:18.520 --> 21:26.360 another, a common way of tagging the footpaths, pedestrian paths next to a road, or like the 21:26.360 --> 21:32.200 pavement is to have it as a separate way. Does it handle that correctly like matching up the 21:32.200 --> 21:37.240 fact that the pavement of the road might sometimes be tagged on the road itself and sometimes might 21:37.320 --> 21:43.240 be tagged as a separate way running parallel to it? I've not been able to handle 21:43.240 --> 21:50.200 separate limit footways in a robot version yet. So, if you tag them on the way, it works, 21:50.200 --> 21:56.200 you get just a curve that is a few centimeters high and then you get the side walk seamlessly 21:56.200 --> 22:03.000 attached to it. If it's a separate footways and you get separate ways next to each other and 22:03.000 --> 22:09.720 whether they line up depends on whether the width is accurate, which is almost never if. I do have 22:09.720 --> 22:19.800 a work, a proof or concept implementation of area highway support, which would also essentially 22:19.800 --> 22:26.760 be easily extendable to that use case because it works on basically shooting rays outward 22:26.760 --> 22:34.120 until it hits an edge that ends the road and then you would at least get seamless transitions 22:34.120 --> 22:47.640 between the sidewalks and the Fenterway. Thanks so much. How does a generic 3D tile server handle 22:49.000 --> 22:53.720 you had textures that had like reflectivity defined? How do you, because 22:54.200 --> 22:59.000 do like does like Google Maps ingest that information when deciding how to render it? 23:03.400 --> 23:09.560 So, in my case a 3D tile server works pretty much as in the 3D tile standard, 23:10.680 --> 23:16.120 which is basically just a tile system that has TFF files as it payload. 23:17.080 --> 23:23.960 So, anything that's supported by TFF or TFF extension can also be inside a 3D tile. 23:26.040 --> 23:31.000 I believe Google Maps, I mean, I've not looked at their implementation but I don't think they have 23:31.000 --> 23:35.880 exactly the same concept and that at least Google Earth had some iterative refinement thing, 23:35.880 --> 23:43.560 which are loads a cause version of the geometry and then increasingly detailed measures added 23:43.640 --> 23:51.320 into that object that more involved than what I do which is essentially just a file that's downloaded 23:51.320 --> 23:58.120 as a single unit and then at that point replaced with a high level of detail tile of the same 23:58.120 --> 24:04.120 location but it's at this creeps that between low level of detail, high level of detail. 24:04.120 --> 24:08.520 So, it's up to the client basically. It's pretty much up to the client. 24:08.600 --> 24:17.480 Yes. I mean, if you export these extra C-thium 3D tiles compatible tiles that 24:17.480 --> 24:24.280 often then it adds a few other bits of information like about the maximum allowed 24:24.280 --> 24:31.160 error and things like that. So, at that point it, you should behave like C-thium in order to have 24:31.240 --> 24:33.160 a standard item implementation. 24:38.280 --> 24:40.280 Some more questions? 24:45.640 --> 24:47.640 No, we've got a question. 24:55.320 --> 24:57.240 Thank you for the presentation. 24:58.200 --> 25:07.560 I mainly wanted to ask about the requirements when it comes to hardware, how accessible it is to 25:09.640 --> 25:15.800 what's going to happen. What are the capacities? You need in your laptop in order to 25:16.440 --> 25:20.200 be able to navigate seamlessly. 25:21.000 --> 25:28.440 Mostly depends on, I mean, you can tune it with, like, unit distance and a few other parameters. 25:29.240 --> 25:37.400 So, I think the most important level to have, like, how far away do you still show objects 25:37.400 --> 25:43.000 and how high is the texture resolution? If there's a low enough then it should also work on 25:43.960 --> 25:48.040 laptop with integrated graphics or otherwise lower specs. 25:50.440 --> 25:56.520 I also have this JavaScript implementation and to do that I also wanted it to work on mobile devices, 25:56.520 --> 26:04.520 which is even harder to give it and it works excellently for individual object or small areas. 26:05.080 --> 26:11.880 The part why the demo doesn't work is that the demo actually loads data quite far away and that 26:11.880 --> 26:17.720 box down the performance too much from a mobile device. But if you don't do that and just 26:17.720 --> 26:23.800 focus on, like, a few buildings or so then it should work on most hardware out there. 26:27.160 --> 26:33.320 Thank you. And if I understood well, you have two ways of doing it, either you choose the bank 26:33.400 --> 26:43.320 of features of little details or you can add your own texture or your own detail, right? 26:48.760 --> 26:55.160 So, essentially, I'm privileged takes parameters for the level of details that you want, 26:56.120 --> 27:05.480 which will then result in quarter or finer grain output and it also lets you essentially add 27:05.480 --> 27:11.800 a matte dial that replaces some of all of the textures that is used by default. 27:13.960 --> 27:20.680 I mean, you could use that to use lower resolution textures in which case it would also have 27:20.760 --> 27:28.440 a performance impact or you could do it if you wanted to look differently to have your own 27:28.440 --> 27:31.720 like visual style and your different texture to achieve it. 27:34.120 --> 27:39.560 It's up to you to make it know that it's for example, Paris and not Berlin, for example. 27:44.120 --> 27:49.160 Well, as I showed the different ways of using the software, 27:50.040 --> 27:55.080 on the command line, you would pass in some kind of latitude or longitude or tile numbers, 27:55.080 --> 28:04.600 which are other just the way of defining a location on the earth, with a free detail client, 28:05.240 --> 28:11.480 you usually have clients that have some search field or something where you type the name of the 28:11.480 --> 28:19.000 location you want to go to. So it depends on the user interface, but it always lets you control 28:19.000 --> 28:26.360 the location in some way. I hope that hopefully I've not come to me after the talk. 28:28.600 --> 28:33.720 So I have another question you said about being able to selectively choose the models that might 28:33.720 --> 28:40.600 be replaced the standard OSM data like use the example of the Eiffel tower. How exactly does 28:40.600 --> 28:47.960 that configuration selection work? Does it happen in a configuration file for OSM to world or does 28:48.040 --> 28:54.040 that happen as tags on the object? Would you be able to do that for custom buildings that aren't 28:54.040 --> 29:03.960 necessarily a known landmark? Both options are possible. So first there is a tag for specifically 29:03.960 --> 29:11.480 this 3D model repository, which some people use inside open street map to add a link to a 3D model. 29:12.120 --> 29:19.080 If you enable that feature on OSM to world, it will replace objects that have this tag with 29:19.960 --> 29:25.880 data from the 3D model repository. You can additionally, in your local OSM to world configuration file, 29:27.720 --> 29:34.200 assign 3D model to particular open street map ideas. So you can say I want node 29:34.440 --> 29:45.720 1,353 to be replaced with the model that's at my model.tf part location on my computer and then 29:45.720 --> 29:53.400 it will use that Eiffel. Is there a contention about using the open model repository inside of open street 29:53.400 --> 30:00.200 map data? Because that feels like it clatters up data a lot of objects. At the moment the 30:00.200 --> 30:07.080 model repository has so few objects that the problem hasn't had written yet. I guess if at some 30:07.080 --> 30:14.040 points there are a thousand millions of models and three community would have to do that. But at 30:14.040 --> 30:19.720 the moment it's so rare compared to like we can meet your comment links or Wikipedia links, 30:19.720 --> 30:25.400 which number is the million that I don't think it has shown up as a problem on many people 30:25.400 --> 30:36.280 3D. I might add some blades of grass to the open model repository. Any more questions? 30:40.680 --> 30:51.000 Well, if not, then we go. Have you had any experience with loading the models into 30:51.880 --> 30:57.640 mapping libraries? So I'm assuming this works with something like CZM, because it's probably pretty 30:57.640 --> 31:04.360 well first in handling models, but not the mapping libraries, I don't know, 31:05.560 --> 31:12.120 not the rest brings to mind. And so I did a prototype of meshing it up with my plea for one. 31:12.120 --> 31:20.280 They have some kind of how to in the documentation of using, I think it was published as 31:20.280 --> 31:30.520 may have been featured as well, to eventually mix up this well, essentially vector tie-based 31:30.520 --> 31:37.240 thing with additional 3D models. And yeah, as a prototype, I essentially hacked in my 3D 31:37.240 --> 31:45.800 tie if you enter that and it works. But at that point, not really a mableeper feature, but yeah, 31:46.600 --> 31:53.320 you're using mableeper to end one part of the scene and then do by hand some extra code that 31:53.320 --> 32:00.280 loads the 3D models into that same scene. So it's not a native 3D tie support, but you can make it work. 32:00.280 --> 32:03.480 You're just sort of loading 3D models into mableeper basically. 32:04.200 --> 32:09.640 Yeah. And if you have that logic, I mean, the 3D tie logic is pretty simple, it's essentially 32:09.640 --> 32:16.120 load in the current location and when you move to where you delete the one that falls off the edge 32:16.120 --> 32:20.600 of the bird and load the new one. So thank you. 32:25.080 --> 32:31.880 Good time for another question. Anyone? If not, then I think we should thank the speaker again. 32:33.480 --> 32:42.040 And that's the end of the bedroom. Thanks very much for coming. See you next year.