 I've been at it for a long time and what you see on the right hand of the screen is what you would call three different ways to represent a location. The one at the very bottom is the full address of where we are right now and the one above it is latitude and longitude and then a number, an integer, which can be converted to latitude and longitude for three words or three geonames. So let's talk a bit about location codes. There is probably, as you know, many ways of representing location, not just with latitude and longitude, but the very famous geohash algorithm, for example, that is used by a lot of people in the open community. There is map codes, there is plus codes, the Google version of that, which is now integrated with Google Maps, and there is a bunch of others, some commercial, some free, that try to address this very problem. So let's step back a moment and see what is an address code, the ways we have come up with to talk about locations. So we have created them in a sense, we just need a way to communicate to other people where we are. So here is where we are right now, and as you see, the problem here is that there is many permutations of how we can represent a location, because Brussels, of course, is a bilingual, trilingual city, and that problem exists in many other places. So people who build location systems point out this very problem, that we cannot just rely on addressing systems, to represent a location with both unambiguity, and this is one of the reasons that they work on this area to come up with a better solution. So what I'm going to present is a hashing function for locations, which takes into account not just latitude and longitude, but also the existing geographical information about the place. So it's just a function of latitude and longitude plus three geonames, which will give us a new code, or less for the geocode, I guess, nobody else has used that name yet, so I might as well use it for myself. So what are the use cases? As you know now, automated vehicles are coming along and pretty soon we'll need to do voice geocoding systems, so basically we need to shout a location across the hall or something like that, so we need to have a geocoding system that is unambiguous and can be communicated via audio. There is also the problem of postcode systems, there is some countries with good postcode systems, others that don't have postcode systems, but even those that do, and in the area where I'm from, Canada for example, it happens that sometimes emergency services go to the wrong location because of the ambiguity in the state names. Here was a, if you click on the link there was a story recently about the fire fighters going to their own house and two poor dogs and a cat dying as a result because Google Maps send them to their own location, and this happens with high frequency, a high frequency I would say, 90% of the time they could be accurate, but the 10% of the time is very high cost. And there's also indoor navigation problems that need to be solved and they can also be solved either by figuring out a way to name locations that say inside the mall by using the names of the stores in a more intuitive human friendly way. So what is my system main attributes? Well it has to be free. There is a couple of systems that are not free as you will know and they rely mostly on the marketing to get the systems into wide adoption. And Google being in the dominant position of course they can just integrate with Google Maps and say, okay everybody use this now and that's clear with that. But the system has to be free. Down the road only such a system will get wide use without any marketing effort. And it has to be short obviously. We need to be able to find the optimal location code. It has to preserve latitude and longitude of special information. So we're basically mapping 2D points into one dimension. And it has to be somewhat memorizable for people to use them. And it has to be unique, which is a feature many systems don't have. Even the popular Geohash function doesn't have this. And thus, but not least it has to be able to be generated offline without internet access and without a database. So at least this is my main requirements. There are a few others, but we'll go through that later. So as far as free, you can just go on GitHub and download the source code and the word list over there. And as far as short, you can judge by yourself. Of course, not into the longitude is not very long. However, it's hard to remember because they seem like a bunch of random numbers. If you click on this one, I don't know if I have linked it, but you can go back. So I've built an API, it's called API3geonames.org. And you just basically give it latitude and longitude. And it gives you all this information. So it's basically the poor man's reverse geocoding engine. So you can either represent this location as Brussels, or Troy. And in this arrangement of every location, the first name is always representative of the place. So we are in Brussels, that's why that is the first one. The other two, though, are not related to the location in question. And let's go back. And I built also like an acronymized extension, which takes these geonames and shortens them further. I'm having a hard time, but I'll hold it. So basically Los Angeles is shortened to LA, as people intuitively know, or Brussels is to BRU. So it's just another layer on top of the system that you can use to even make the location names even shorter. And as far as special locality goes, obviously, as I said, in the three-geoname version, they always share the first word. Let's say this place is close to Halifax. So Halifax will be the first one, but the other two are quasi-random, in order to enable us to avoid errors in the transmission of the locations. But, as you can see, equivalent geocodes of these are completely different of this point and that point, although they are only one meter apart. So special locality has to take care of this. Also, if you were going to use a long code like this, it will share most of the significant digits. Or if you're going to build a three-name code, then it has to share the first word. Now, as far as memorisable, that's debatable as to what people can remember easily. I find it easier to remember this. Brussels will try this as I can remember this one, that is the Google Plus code equivalent of that. This is the three-word version of that, and this is the geohash. As far as unique, it has to be unique both ways. And as you know, this is another problem with the popular geohash algorithm. Because geohashes such as this and that, they all decode to the same point. Which is this one here. So we have to avoid this problem moving forward. Deterministically speaking, you can just get the code that's written in Perl. It's on cpan, and you use it in that way, just embed it into your system. And you don't need a database or anything else. You just install it on your laptop and you're good to go. And like I said, I have an API. I think I clicked through to it. So the API is free, and it runs on, well, there is a little bit of documentation, not much. But this is very simple, so why go any further into detail. The API is free. It's running on a micro instance on Amazon, so it doesn't cost me anything for a year. As you know, Amazon has these nice specials about one gigabyte memory and one CPU. But it can only handle about 100 requests per second. If you do more, it might crash the server. So if you are so inclined, you can also get your own server on Amazon. Because there is an image there that you can launch your own machine with over there. And it looks kind of like this. And as far as cloud performance, like I said, it could do 100 to 200. But it depends, and I'll get into a little bit why this difference in the performance. It depends on the point. Sometimes if you have a point that is like in the middle of Brussels, it's faster to reverse-geocode than the point that is in the border. And I don't want to go too much into the algorithm, but the algorithm is just relying on partitioning the Earth into a grid. And the user skip-list does a structure to name each one. So for example, you can shorten them. Let's call them geo-polygons. And this is the location somewhere in the Pacific, close to the 108th Meridian. And you will get simple polygons such as this one of about 21,000 square kilometers. And you can shorten it further and you get something like this. So unlike many systems that I've seen, these polygons are not, in a sense, squares or pentagons or hexagons or whatever. They're kind of the mathematical function that guides their generation. It just makes it so that it's simple polygon if you have only one word. It's a convex polygon if you have two words. Otherwise, and in the last stage, it's just one meter by one meter square. So it's a resolution of one meter. And this is where we are right now. And this is one of the problems with this naming system. There is locations, there's a place in Tirana where I'm from, Albania. It's called Krap. So you will have a location called Brussels or Krap. And it's that there. However, what can we do about dirty words? They exist. That's why this is open source. And if you don't like these words, these names, you can replace them with your own. I just came up with this for a very good reason because I want the names to be distinct from each other, to have good Levenstein distance. So when we shout them across the hall, they are not mistaken for a different name. But people are free to tinker with it. There are some considerations. There is 658, almost 659 trillion latitude and longitude points. If you limit them to the fifth decimal point, which accounts for one meter of resolution. So you need around 150,000 geonames to get the system to work. Like I said, I have two versions of the code. One is at one meter and one is at 10 meters. And I will get to it very quickly why I do that. See, when I do the reverse geocoding, I need to have like overlapping polygons to make sure that something on the border doesn't get mischaracterized. So that's why I have two systems laying on top of each other to solve this problem. And my main goal for building the system in the first place is not location encoding per se. I don't really care much about building a geohash, but I wanted to build a faster reverse geocoding algorithm. So point in polygon queries are very fast when you use number ranges. Let's say from that number to that number is the numbers that represent all the locations inside Brussels. So when you are looking at it, you can have a constant expected time complexity, which is 90% of the times. But if you are close to the edges, then you probably, in the worst case, you go to logarithmic time complexity, which is acceptable. But this way, you get a much faster reverse geocoder than if you were to use some other technique. Just a quick recap. There are two different codes that I've come up with. One is called the three geonames, based on geonames. They are open, they are free, and I don't think anybody can copyright that. And there is the second option, which is one geoname and the number extreme no longer than five digits. That represents a 10 by 10 meter cell. As far as navigation, the second one would be working just fine as well, but people want the highest resolution, and one meter by one meter is, I think, more than sufficient. There is some other attributes. Of course, this uses the Hilbert curve for obtaining best location proximity, and it's really fast because you're just flipping bits. And there is a combination that I use the Hilbert curve with the Zorder curve to get this overlapping arrangement. And there are no discontinuities, and that's a 180 meridian if you can go to the website. Maybe if I have time, I don't know how much time I have. I can give you a quick demo. Okay, I have another 15 minutes, which is great. So basically, you can solve this problem on the dateline and this extantible. Now, the process is mostly CPU intensive. So if you go and use a minimal instance, it will work fine, but you can scale up to 200 million points a day on 24 cores. So memory is a factor too. The data comes from open places like GeoNames and OpenStreetMap, and there is 12 million of them, but you can easily fit that into one gigabyte of RAM, no problem. And even if you grow the RAM, it will not make a difference. But CPU is important to get more throughput on this system. So there are some to-dos. I haven't gotten around to other languages. I thought about doing it before I came to this presentation to just get the GeoNames alternate names field and to just produce a couple of options, but I'll let other people tackle the problem if they feel so inclined. And as far as error correction, you could also... What I've built is... See, each of these 150,000 words has a certain added distance, both on the audio sense and the character sense, from each of every other ones. So basically, I've picked my GeoNames carefully to have them as distant as possible, but you can modify this algorithm to get them even more distant from each other. But bear in mind that in order to keep the words short, you have to put up with a distance of one. Otherwise, you will end up with long words if you want to get longer and longer distances and these things to be more and more distinct for each other. All right, so... I still believe that encoding geographic coordinates, it's very trivial. I mean, come on, it's just... Have you seen this movie, The Hot Sucker Proxy? It's one of my favorite movies. And this guy here just came out of business school and he said, look, I've invented the circle. And it became an instant commercial hit because he invented the hula-ho. And it's trivial, right? But there is many companies that are building business models around this. And a lot of people in the open-street map community, for example, are really annoyed with companies like What Three Words, or Zipper, who are trying to copyright word lists and getting people to use their system to find that attitude. But I don't have to be mad about that. Just try to make it better and try to make it work and improve of those things. And a lot further ado, I think I have a few minutes. Before I go to questions, there is a website I put up. Well, it defaults to that, but I should come back to where we are. So, let's say you can... This is both a reverse geocoder and a geocoding system. Sorry, I clicked on the wrong one. So, basically, you get that. You get these brussels. Langco, at least it's not crap. Well, crap is the next meter of... So, if I was sitting... I don't know how geolocation works on this thing. But you know what I mean. And there are three options. You can either represent it like this, or as a string, an alphanumeric string, or as both a name and a little string at the end of that. And, of course, you can also go to the API and check it out over there. So, that's pretty much what I had to say. Just go... And one more thing. When you go to this, you can also use... I'm trying to copy and paste this thing, all right? Not having any luck. I forgot how to copy and paste. There you go. So, if you add .json in the end, especially many JavaScript programmers like this, you just get that. And... Or you can put the 3GName version here. So, like this. And it's the same thing. So, that's it for now. Let me know if you have any more questions. Questions? Yeah, of course. That's the underlying... Well, it's a function that transfers latitude and longitude to a single number. So, it's basically using the Hilbert curve to have these numbers sequential. So, let's say two latitudes and longitudes that are close together here and the chair over there would have very close dual numbers, like different by one number or two. It's part of the open source, yeah. Yeah, I mean, the Hilbert curve is open source. There's other implementations of the Hilbert curve that could do exactly the same thing. Why do I want a unique? I don't know. I thought it would be... As a mathematician, I think one-to-one functions are better than things that are less predictable than that. I want to be able to say that I'm at exactly this unique code as opposed to I could be at this or that or those other ones. I thought it would be a good requirement. Maybe it's not. I don't know. You can remove that requirement if you like. Oh, yes. I can probably show you. See, geocode.xyz is a reverse geocoder, basically. This is why I built it. So right now, if I go to Cloudflare, there's about... Well, no, not this one. There is about... Oh, for some reason, I'm not good. But there's about 100 million requests for months on this API, but people don't usually use it for the geocode themselves. They just want to use a reverse geocoding engine for fleet tracking, for things like that. For example, for... I don't know, for drone navigation or multi-storey coding, you mentioned the Insta application. What do you think about that? Yeah, I think the Geohars 36 algorithm has a feature that they include elevation as well. I've looked into it. It's easy to add it to this one, but I will need to add another byte to the length of the code to be able to encode elevation as well. Does the Geohars have a think about the third dimension? That is very important, especially people you do drone delivery. They want to have this feature embedded into that so they can also encode elevation as well as latitude and longitude. It's totally possible. The Hilbert curve was built not just to transfer two dimensions to one dimension, but to transfer three dimensions to one dimension in the same easy way, just a number of bits, a little bit longer. No, Hilbert curve is much better than the Z-order curve, which is what the Geohars algorithm uses. The Z-order curve is much easier because you're just interleaving the bits and it's simpler to implement. The Hilbert is a little bit more complicated, but it does preserve location proximity much better than that. Well, Hilbert is better than Piano Code. Because Hilbert was based on Piano Code. It was an improvement over that. From what I've seen, I use both Z-order and Hilbert curves on top of each other. So when there are some things that are bad on one of them, I correct it by the other one. As far as reverse geocoding goes, I don't think I'll miss anything by using them both in superimposed and challenge. Thank you. What do you think like this, within the data in terms of what happens? The type? The type, yeah. Sometimes there is land and sometimes there is not because of the type, because of the motor. Oh, I see. See, I haven't really bothered much with taking into account temporal displacements. Basically, I just get a latitude and longitude into a number and that number into a code. You know, Australia is moving with one meter in 10 years or something. So I don't deal with that. The latitude and longitude will move with Australia. So you will be a different code in a few years from now. One of the first part of the pre-code is an insight into the model. Yeah, it's always like that. Considering that, that question, because I think at one point we'll Sydney something something in the ocean. That's something that's far in the future. That is a very good question. And you're right. No way. Australia will, in about 100 million years, this will no longer be relevant. Because that's why somebody needs to update it. Because these numbers are assigned to cities as they are today. And then you have the main name. But if you change, everything is open. Okay, that was the last question. Once again, thank you very much. Thank you. Thank you very much. Can we get this presentation done? Yes. Is Fisarion present? Hi. I'm on you. Here you go, sir. Sorry? Uh-huh. It's on the... Okay. Then...