WEBVTT 00:00.000 --> 00:13.360 OK, let's start. I'm a Christian guest. I'm coming from France, so I have a French accent, 00:13.360 --> 00:22.560 sorry. I'm involved in open-suit map for many, many years, and I'm here to, to, I'm here 00:22.560 --> 00:27.760 for the first time to explain what is a new project we started, which is called Panorama 00:28.240 --> 00:38.240 the idea of Panoramax is to create a new common, a new open database of interesting things 00:38.240 --> 00:46.960 with a non-profit aspect in the project. The resource is a big, large growing catalogue of 00:48.160 --> 00:56.080 street-level, ground-level pictures. The rules, which is important in a common, it's to have 00:56.080 --> 01:06.240 open license, I've all our software stack being open, and as much as possible, use existing standard 01:06.240 --> 01:14.480 do not create exotic stuff, and this is very important. The community, it's anybody who 01:15.520 --> 01:20.880 respect the resource, respect the rule, it can be a public sector, it can sit my contributors, 01:20.880 --> 01:28.960 projects sector, company, etc, etc. So, really, the project is to create a new way to share ground-level 01:29.920 --> 01:37.680 photo pictures. So, of course, everybody has in mind Google Street View, so it's not Google, 01:38.400 --> 01:46.720 not on these streets, and you can do much more thing than just view the picture, because if you 01:47.600 --> 01:54.240 read the rules about Google and others, you are limited to what you can do with the pictures. 02:01.040 --> 02:08.320 So, why? Because we really need a really open alternative to what is existing. So, all our 02:08.320 --> 02:15.120 code is published on GitLab, and you can have a look at that. It must be independent of private 02:16.080 --> 02:22.960 interest, by I would, etc. I'm sure you have heard of Mapidari. You may not have heard that Mapidari, 02:22.960 --> 02:31.120 a couple of years ago, has been built by Meta, and a lot of small change happened, and it was a 02:31.120 --> 02:37.680 bit a problem for the future to depend on that kind of things. We also want to have an open 02:37.680 --> 02:42.960 governance, to have as much people as possible deciding, not deciding in a small team. 02:43.840 --> 02:51.840 A very important point, I hope I have enough time to extend that, is have something decentralized, 02:51.840 --> 03:01.440 because such a project is a storage challenge, and if one entity has to store all the picture 03:01.440 --> 03:09.920 for all the world, it goes into a problem one day. So, we want to go in a decentralized, 03:09.920 --> 03:18.400 federated system. An easy and full access for original picture with easy to use API to get 03:18.400 --> 03:24.560 the picture at the access of the picture. Based on existing some parts, I already said that, and 03:25.520 --> 03:30.720 we did not start from scratch, we reused existing code, and we improved existing code, 03:30.720 --> 03:36.560 which is, I think, the spirit of open source really that. So, the idea is to avoid the 03:37.040 --> 03:44.000 point of failure, that's very important. So, the original idea is not new, because it's something 03:44.000 --> 03:53.520 I proposed to the French geographic institute in 2012. But, Mampil, I restart one year later, 03:53.520 --> 04:02.800 I said, okay, let's go with them. We start, we proposed that again four years ago, and I 04:02.800 --> 04:10.000 GN decided to go for it a little more than two years ago. So, it's currently funded by public 04:10.000 --> 04:17.200 money in France. We have a small team working on the project, but with a very, very, very open 04:17.200 --> 04:23.840 way of working. We release the first version of the platform where you can upload picture 04:24.720 --> 04:34.560 in mid 2023. We got a grant from an internet recently to have mobile app. So, that's really the 04:34.560 --> 04:40.720 dynamic of the project. So, how does it work? The idea, the decentralized thing, 04:40.720 --> 04:47.680 make the ideas to have instances, and its instance is taking care of the storage of the picture 04:47.760 --> 04:54.000 themselves. It's creating a local catalogue of the available picture and exposing that catalogue. 04:55.040 --> 05:04.960 We also have an API and an user interface to upload picture. And we also have an API to see it 05:05.680 --> 05:12.320 in the catalogue, and we also have a viewer to view the picture, to browse, to go from one picture 05:12.400 --> 05:19.120 to another. One important thing is we have a blurring service, because we cannot publish picture 05:19.120 --> 05:24.800 with people face or license plates on the car. So, we have a blurring service, and we built it 05:25.920 --> 05:31.600 completely. We trained our own model, et cetera, et cetera. It's also something that is 05:31.600 --> 05:39.920 completely open. So, it detects face license plates, but we also detect more like road signs. 05:42.320 --> 05:47.120 All the model is fully open, even the data that we use to train the model. They are open, 05:47.120 --> 05:52.480 except the one for the face detection, because of course, there's people faces in that, and 05:52.480 --> 06:01.200 we cannot make them public. And on top of the instances, we have the panorama metacatalog, 06:01.200 --> 06:09.280 which creates the federation between them. So, you can query the metacatalog, the same way 06:09.280 --> 06:17.920 as you query an instance, the same API. So, one instance, how does it work? What is the 06:18.800 --> 06:26.320 thing? You can store the picture locally on disk, or you can store that on services, 06:26.320 --> 06:33.120 which are based on the S3 protocol. It doesn't have to be AWS. It's just the protocol. 06:34.000 --> 06:41.040 For the S3's T-picture, there's not only S3's T-picture, there's mix of pictures, but for the 06:41.040 --> 06:47.680 one, we are pre-cutting them to have a faster display. So, it's something that is done. We keep 06:47.680 --> 06:54.080 all the original metadata in the picture, the location, of course, but also all the metadata 06:54.080 --> 06:59.920 about the camera that took the picture, because it's very interesting to do a post processing of 06:59.920 --> 07:07.760 picture to have to keep that information. The local catalogue is built on post-rescue L, 07:07.760 --> 07:17.360 the code is Python. We have, for the API, I said we want to stick to existing standard, 07:17.360 --> 07:23.360 and we found the standard that is called stack spatial temporal assets catalogue. It's designed 07:23.360 --> 07:31.120 originally for AI, AI imagery, or satellite imagery, but there's an extension in that 07:31.120 --> 07:36.880 standard for what they call perspective imagery, I call that horizontal imagery, 07:36.880 --> 07:43.200 and not vertical. And so we stick, we try to stick as much as possible to that existing 07:43.200 --> 07:51.440 standard. So, it's just on that supported by big names, Airbus, Maxar, Nazar, 07:52.720 --> 07:59.760 names who already heard, I think. And as we stick to this standard, there's already 07:59.760 --> 08:09.360 tools that works directly with what we did. The upload API is outside of stack scope, so it's 08:09.360 --> 08:20.080 something we created from scratch. A upload, that's what most people will do with Paranox is 08:20.080 --> 08:26.720 publishing pictures, so we have different ways to upload picture to Paranox. We have a web interface, 08:26.720 --> 08:33.520 we have a command line tool, which is designed more, when you have mass upload, when you have 08:33.600 --> 08:39.520 thousands, hundreds, or thousands, or even, sometimes millions of pictures to upload. It's the 08:39.520 --> 08:45.600 good tool, and the API can be used directly. The web interface or the command line tool, 08:45.600 --> 08:52.000 use the API and the API can be used by other application tools, etc. Mobile apps, etc. 08:52.000 --> 09:03.760 The upload system detects duplicates, when you go around and go twice in the same place, 09:03.760 --> 09:11.040 we detect that, it will split the upload in sequences and things like that. As we have a 09:11.040 --> 09:18.000 decentralized system, we have different instances, and each instance can choose things like 09:18.000 --> 09:22.240 the license. For the moment, we have two public instance, where you can upload picture, 09:22.240 --> 09:27.440 the one from the geographic institute, IGN, and the one from append suite map friends. 09:27.440 --> 09:34.080 The difference between them is, at least, the license on which, and on, with which you publish 09:34.080 --> 09:41.760 the picture. For IGN, it's CC by, because it's the usual kind of license that is used by the 09:41.760 --> 09:48.000 public sector. But for open suite map, we like the share-alike principles. So, our picture 09:48.000 --> 09:56.880 are published in the CC by SA. With one additional thing, that we grind the right to create 09:56.880 --> 10:07.040 non-geographic, non-photographic, derivatives like database, under CC by, or ODBL license. It's 10:07.040 --> 10:13.040 a requirement, because if we don't have that, you can not use CC by SA picture to improve 10:13.040 --> 10:22.160 open suite map, because the license is not compatible. Open suite map, friends, instance, 10:23.760 --> 10:32.960 we have, okay, just to make sure I'm not too slow. It's full-bar metal option, 10:33.600 --> 10:39.360 because cloud service is way too expensive for what we want to do. So, we have a server. It's 10:39.360 --> 10:47.360 located in the data center near Paris. We have two 10 gigabyte fiber. It's fully second-end hardware 10:47.360 --> 10:54.640 except the SSD with you. It's only pieces that are new. So, it's the kind of server we have been set up, 10:54.640 --> 11:02.720 okay, total investment so far is 5,000 euro, which is not lost. And we accept 11:02.720 --> 11:11.520 pictures outside the friends, but for testing purpose. We cannot ask millions of pictures from 11:11.520 --> 11:19.120 everywhere. We will not have enough storage for that. And we really encourage people who want to 11:19.120 --> 11:25.920 step in panoramic to work on setting up instances. That's really what we need right now. 11:26.240 --> 11:35.280 It looks like that. My hardware, and when it, that's to set up in the, in the bay, 11:36.000 --> 11:43.680 you have five of them like that. So, we can have 60 large drives in the bay. So, 11:44.480 --> 11:51.440 currently we have 240 terabytes in the server, and we use two sort of that, and it's growing quickly. 11:52.080 --> 12:00.240 So, the Metacatalog, as I explained, is it's what creates the federation between the server, 12:00.800 --> 12:07.840 and so it's harvesting the server regularly every couple of minutes, because we have a different 12:07.840 --> 12:15.520 shoulder updating system that allows not to collect all the catalogue every time. And it 12:15.520 --> 12:20.400 messes that in one single database. It keeps on leading the metadata. There's no copy of the picture 12:20.400 --> 12:25.680 themselves, because otherwise the Metacatalog will have another storage problem. And it provides 12:25.680 --> 12:32.800 exactly the same stack API as the instance. And so, it creates a seamless access to all the 12:32.800 --> 12:40.640 picture, whatever server they are located on. So, you can have a look at what it looks on 12:40.640 --> 12:48.800 API.panorama.xyz, and I'm going to try to do a small demo. 13:11.600 --> 13:21.920 So, as you see, the coverage is really focused on friends. And when you browse, you, 13:23.120 --> 13:35.360 okay, by zooming in, you will find pictures, and this. So, we have not only, we have 360 pictures, 13:35.360 --> 13:43.600 but we all have no 360 picture like this one. So, there's a real mix of kind of pictures. 13:46.320 --> 13:53.120 Okay, try to find, you have filters. For example, it's I want to see only 360 pictures. 13:55.200 --> 14:02.080 We also have quality score on the picture, depending on the resolution, and depending on the location 14:02.080 --> 14:09.680 accuracy and things like that. You can also filter to see only pictures shots between dates, 14:09.680 --> 14:16.080 etc. Oh, you can also see it for user and only see the picture that has been shared by that 14:16.080 --> 14:26.640 user. So, you can mix all that if you want. So, if I look at that, I will have 360 pictures of the 14:26.720 --> 14:39.680 area. And then you can move, that's the sequence, you see the blurring. So, you have more or less a global view 14:39.680 --> 14:45.680 of, this is the part, no, I'm actually not only that, you can have access to the picture. So, 14:47.040 --> 14:54.640 direct access to the picture is with the sharing button. You have directly to download the full 14:54.640 --> 15:02.000 resolution picture, you can have a link to include that with a knife frame, etc. etc. You can print it 15:03.440 --> 15:10.800 and you also have all the meta information about the picture. So, this has been shared with 15:10.800 --> 15:21.760 GoPro Max. Okay, you have the direction, etc. etc. Okay, so this is more or less what you see on the 15:21.760 --> 15:45.840 panoramax site. Up, I'm just okay. So, panoramax, of course, can be used to contribute to a 15:46.160 --> 15:53.280 panoramax site map. So, we have both instance, the IGN open sheet map. One, I have compatible 15:53.280 --> 16:00.800 license for that. And there's already integration in the OSM ecosystem. For example, the open 16:00.800 --> 16:07.280 sheet map friends instance, to log in these instance, you simply use your open sheet map 16:07.920 --> 16:13.680 accounts. You don't have to open an account. There is a direct access from ID, the web editor, 16:13.760 --> 16:19.360 the web based editor in open sheet map. And there's a plot integration that is already in some 16:19.360 --> 16:27.120 build apps like map complete. There's this poochie and every door is thinking about it. So, it's really 16:27.120 --> 16:34.160 moving. The future is really more instances. That's really the thing we want to promote. I hope 16:34.160 --> 16:39.600 there will be a Belgium instance very quickly. There's some French local authority who are thinking 16:39.600 --> 16:46.800 about it. And more picture, of course, we are getting close to 50 million pictures. We, in the past 16:46.800 --> 16:52.800 months, the rate of new picture was more or less a 3 million picture per month. More plot 16:52.800 --> 16:59.440 options. There's already a mobile application called Baba, which is available on Android. And we 16:59.440 --> 17:08.720 are working on a panoramax application. And, well, larger community, we also think about creating 17:08.800 --> 17:18.000 an international federation for the project not to stay too much French centered. Do you have 17:18.000 --> 17:28.000 questions? 17:38.720 --> 17:53.680 Yeah, okay. Do you think it's possible to add pipelines to extracting formation from the 17:53.680 --> 18:03.760 picture that could be useful for open sheet map? Well, it's difficult to integrate all the 18:03.760 --> 18:13.120 kind of pipelines in the panoramax platform itself. I'm more focused on doing some extraction 18:13.120 --> 18:24.160 of pictures in an area and doing things on that. And I think what we need to share is the trend model. 18:24.240 --> 18:34.640 We do. If we trend model to detect transport the stops, for example, it would be nice to share 18:34.640 --> 18:40.320 that model so that we don't have to do all over again the same thing. But then running the model 18:40.320 --> 18:45.760 on some pictures, I think it will be something more local, not global. 18:46.320 --> 18:56.800 Yes? Two questions. What's the use of panoramax and the second one? How easy is to host the 18:56.800 --> 19:04.800 instance? So, do we support indoor picture? We are not against indoor picture. There's nothing 19:04.800 --> 19:10.400 in panoramax that will detect that it's an indoor picture and will reject it. But you need to have 19:10.480 --> 19:16.720 authorization for that because most of the time in the picture are in non-public places. So, 19:16.720 --> 19:24.080 panoramax is limited to the public space. But if you take, for example, a trend station, 19:24.880 --> 19:30.960 it's a space open to the public, but it's not public space. You need to have authorization. 19:30.960 --> 19:35.360 At least in France, in other countries, I don't know. But this is one thing. And the other question 19:35.360 --> 19:42.080 was, how is this to host? How is it to host an instance? It's not complex to set up. 19:43.120 --> 19:51.360 It's not complex to maintain. The really difficult part is storage. Our much storage can you put 19:52.720 --> 19:59.760 and it will be growing. So, okay, I did a calculation for France. If you want to have a full 19:59.760 --> 20:11.120 coverage of France, then it's more or less 100 million pictures. It's more or less with redundancy 20:11.120 --> 20:21.680 and backup one petabyte. So, how much will cost you your one petabyte? If you rent it, forget it. 20:21.760 --> 20:32.240 If you buy it, you, if you buy it with use equipment, you can get that for 15, 20,000 euro. 20:36.560 --> 20:38.000 Which is an investment, yes? 20:39.440 --> 20:47.120 How do you filter the uploaded images depending on their quality? Like people don't have necessary 20:47.120 --> 20:53.440 in the same capturing hardware. So, how do you harmonize that? Do you even harmonize it? Like 20:53.440 --> 21:00.240 do you keep all the photos everyone sends? Yes. So, about the quality evaluation of the quality of the 21:00.240 --> 21:06.080 picture, we accept everything. The only requirement is we need the geolocation and we need the data. 21:06.640 --> 21:12.720 That's all. We don't ask anything more. But then, okay, we compute some quality index 21:13.280 --> 21:22.480 and it's based on the horizontal resolution. So, if you have a very wide angle, but not a lot of pixels, 21:22.480 --> 21:30.000 it's not as good as not that wide angle and the same amount of picture because you have more 21:30.000 --> 21:33.520 resolution. Yes? 21:33.600 --> 21:38.320 How do you handle up all the photos? All the photos? 21:38.320 --> 21:44.080 I can't do the dates correctly. What could you do? Like the view does end of the upload 21:44.080 --> 21:52.320 of the whole date of all photos correctly. Okay, dates them by the time of the upload, 21:52.400 --> 22:08.160 the time of the 2018. What? We, about the date and old picture, we depend on the data that is in 22:08.160 --> 22:16.800 the metadata. So, if it's wrong, it's wrong. But another question is, what to do with old picture? 22:16.880 --> 22:23.120 Do we keep them for our long? We have no, for the moment we keep everything. And of course, 22:23.120 --> 22:29.280 when we will be short of storage, we will have to think about it. I think it's over if you want to 22:29.280 --> 22:37.360 meet us, we have a boost in the K building level 2. So, we have some goodies too. So, please 22:37.920 --> 22:44.160 come and see us. Thank you.