3Geonames.org
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Ruci, Ervin
Encoding geographic coordinates into a string is a trivial thing. Yet, there are many grid based systems (geohash, PlusCodes, Mapcodes), and some even turn the thing into a business (Zippr, What3Words). I agree with the commonly stated motivation that Latitude and Longitude are not sufficient for identifying a place in both an unambiguous and human friendly way. A single string for this pair of numbers is a better representation, if only it can preserve all the information contained in the original latitude,longitude pair, something no existing geo-encoding system does. That's my goal. Geocode is a one-dimensional location code. It uses a simple space-filling technique to map a two dimensional point (latitude,longitude) to either an alphanumeric string or a geoname triple with no loss of information. It is a one-to-one mapping (no two geocodes map to the same point and no two points map to the same geocode). Geocode has several advantages over similar systems. The alphanumeric geocode is short (10 bytes), has higher accuracy (up to 1 meters) and avoids the borderline discontinuities and many to one mappings of other one-dimensional location codes such as geohashes. Triple geoname codes on the other hand are more memorizable, are intuitively reprentative of the location and are composed of relatively short existing geo names (up to 8 letters). The first name in a triple geoname code represents the most prominent location name inside a 21,403 km² area containing the point. For example, 34.05223,-118.24368 (a location in Los Angeles), is encoded to EKEAJ18E08 or as three geonames: LA-GASPAR-YANSI or as a hybrid code LA-MJKQH4. Another location about 1 m away, say (34.05223,-118.24369), is EKEAJ18E1D or LA-GASPAR-HINGWEN or LA-MJKQI9. The human readable algorithm uses 146300 geonames from and_countryfiles.html with several requirements for the names (chosen to be recognizable, short, easy to pronounce, distinct from each other and evenly spread throughout the earth.) We also shorten geonames to their acronyms whenever possible (LA → Los Angeles, NY → New York, etc) Unlike many grid-based location codes, geocodes represent points not areas. Each geocode maps to a latitude,longitude pair with accuracy up to the 5th decimal point (i.e. 1 meter) In a nutshell, latitude,longitude values are represented as two linear curves, converted to binary numbers then combined by interleaving their bits. As a result of this technique, similar geocodes are located geographically close together in both alphanumeric and triple geoname formats. A geolocation expressed as (latitude,longitude) can be converted offline into a geocode, and vice versa using a data structure embeded in the software. The software is in the public domain to be used without any restrictions.
 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 geo names. So let's talk a bit about location codes. There is probably as you know many ways of representing location not just with longitude but the very famous geo hash 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. Let's 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 the 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 three lingual 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 on ambiguity and this is one of the reasons that they work on this area to come up with a better solution. So what I am going to present is a hash function for locations which takes into account not just latitude and longitude but also the existing geographical information about the place. So it is just a function of latitude longitude plus three geonames which will give us a new code. Let's call it 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 will need to do voice geocoding systems. So basically we need to shout 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 post code systems. There is some countries with good post code systems others that don't have post code systems but even those that do and in the area where I am 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 firefighter going to their own house and two poor dogs and a cat dying as a result because Google maps send them to the wrong location. And this happens with high frequency, high frequency I would say. Ninety percent of the time they could be accurate but the ten percent of the time is very high cost. And there is also indoor navigation problems that need to be solved and they can also be solved either by figuring out a way to name locations I 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 a dominant position of course they can just integrate it into 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 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 the database. So at least this is my main requirements. There are a few others but we'll go to 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 it's 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 API 3Gernames of Lord 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 boat. And in this range of every location the first name is always representative of the place. So we are in Brussels that's why that is the first name. The other two though are not related to the location in question. And let's go back. And I have built also like an acronymized extension which takes these geonames and shortens them further. I'm having a hard time. 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. As far as special locality goes, obviously as I said in the 3Gername version they always share the first word. Let's say this place is close to Halifax. So Halifax will be the first one. And 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 like a long code like this it will share most of the significant digits or if you're going to build three name code then it has to share the first word. Now as far as memorizable 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 Google plus code equivalent of that or this is the three, what 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 this written in pearl, it's on cpan and you use it in that way. Just embed it in 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 this nice special about one gigabyte memory and one CPU but it can only handle about 100 requests per second if you do more than 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 borders. 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 they use a skip-list data structure to name each one. So for example you can short of them, let's call them geopolygons 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 the sense squares or pentagons or hexagons or whatever, 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 state is 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 is a place in Tirana where I'm from Albania, it's called Krap. So you will have a location called Brax, 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 a lot of, 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 ten 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 and coding per se. I don't really care much about building a geohash but I wanted to build a faster reverse geocoding algorithm. So point and 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. So 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 non-photon numeric string 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 Zordr curve to get this overlapping arrangement and there are no discontinuities even at the 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. I have another 15 minutes which is great. So basically you can solve this problem on the data line and this extantable. 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 geo names and open street map 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. It is possible, I thought about doing it before I came to this presentation to just get the geo names, alternate names field and to just produce a couple of options but I will let other people tackle the problem if they feel so inclined and as far as error correction you could also, what I have built is, see each of these 150,000 words has a certain added distance both on audio in the audio sense and the character sense from each of every other ones. So basically I picked my geo names 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. Alright 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 hoop 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 and not to use it but 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 I'll have further ado, I think I have a few minutes I just before I go to questions there is a website I put up, well it defaults to that but it 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, ah, Langkou, at least it's not crap, well crap is the next meter of, so if I was like sitting, I don't know how geocaching 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, 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 control copy instead of latitude and longitude you can also use like the number of the location oops, oh wait, I'm trying to copy and paste this thing, alright, ah, not having any luck, I forgot how to copy and paste, there you go, so if you add a.json in the end especially many JavaScript programmers like this, you just get that and ah, or you can put the 3G name version here, so like this and it's the same thing, so that's it for now, ah, let me know if you have any more questions. We have about seven minutes left, 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 this number sequential so let's say two latitudes and longitudes that are close together here and the chair over there would have very close geo numbers like different by one number or two. Right, and is that a part of this or is that a generic or is it part of your open source? It's part of the open source, yeah, yeah, I mean the Hilbert curve is open source, there's other implementations of Hilbert curve that could do exactly the same thing. Anyone else? Please, why do you want a unique geo curve for your location? Why do I want a unique? I don't know, I thought it would be, right, as a mathematician I think one to one functions are better than things that are less predictable than that, like I want to be able to say that I'm at exactly this unique code as opposed to I could be 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. Anyone else? Is it might be you? Sorry? Is it might be you? Oh yes, I can probably show you. See geo code.xyz, it's a reverse geo code basically, this is why I built it. So right now if I go to cloud flare, there is about, well no, no, this one, there is about 100 million requests for months on this API, but people don't usually use it for the geo code themselves, they just want to use a reverse geo code engine for the fleet tracking for things like that. I think the geo hars 36 algorithm has a feature that they include elevation as well. I'm looking to 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. 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 latitude. So it's totally possible, like 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 will be a little bit longer. That's all. No, Hilbert curve is much better than the Z-order curve, which is what the geo hash 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. But from what I've seen, and I use two different, I use both Z-order and Hilbert curve 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. So as far as reverse geocoding goes, I don't think I'll miss anything by using them both in superimposed and challenge. Thank you. Q. Are there mixes with seasonality, meaning the tides or the elevation of snow or things like this within the data in terms of how to... The tides? Q. The tides, yes. Sometimes there is land and sometimes there is not, because of the tides, because of the tides. Q. I see. See, I haven't really bothered much with taking into account temporal displacements. Basically, I just get latitude and longitude and convert it to 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. Q. Since you're using the first part of the code, is there a location inside of that? It's always like that, for example... That is a very good question. And you're right. 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... Q. Okay, that was the last question. Once again, thank you very much. Q. Thank you. Q. Can I ask you a question? Q. Can we get this presentation done? Q. Yes. Q. Is Fisario present? Q. Yes. Q. Is Fisario present? Q. Hi. Q. I'm from Europe. Q. I'm from Cambridge, Canada. Q. I'm from Cambridge, Canada. Q. Sorry? Q. Can you give me your presentation? Q. Yes. Q. Yes. Q. Yes. Q. Yes. Q. Yes. Q. Yes. Q. Yes. Q. Yes. Q. Yes. Pahrt, permit. Mbappata. Here is the delay. OK. OK. So, let us move on. So, let us move on. Pahrt, you introduced yourself. After the 2th quarter of this program, what led you to such a strong union that G ak Or Kilbis was given to you here on the drivetrain?
 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 geo names.  So let's talk a bit about location codes.  There is probably as you know many ways of representing location not just with longitude  but the very famous geo hash 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.  Let's 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 the 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 three lingual  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 on ambiguity and this  is one of the reasons that they work on this area to come up with a better solution.  So what I am going to present is a hash function for locations which takes into account not  just latitude and longitude but also the existing geographical information about the place.  So it is just a function of latitude longitude plus three geonames which will give us a new  code.  Let's call it 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 will need to do voice  geocoding systems.  So basically we need to shout 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 post code systems.  There is some countries with good post code systems others that don't have post code systems  but even those that do and in the area where I am 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 firefighter  going to their own house and two poor dogs and a cat dying as a result because Google  maps send them to the wrong location.  And this happens with high frequency, high frequency I would say.  Ninety percent of the time they could be accurate but the ten percent of the time is very high  cost.  And there is also indoor navigation problems that need to be solved and they can also be  solved either by figuring out a way to name locations I 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 a dominant position  of course they can just integrate it into 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 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 the database.  So at least this is my main requirements.  There are a few others but we'll go to 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 it's 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 API 3Gernames of Lord 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 boat.  And in this range of every location the first name is always representative of the place.  So we are in Brussels that's why that is the first name.  The other two though are not related to the location in question.  And let's go back.  And I have built also like an acronymized extension which takes these geonames and  shortens them further.  I'm having a hard time.  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.  As far as special locality goes, obviously as I said in the 3Gername version they always  share the first word.  Let's say this place is close to Halifax.  So Halifax will be the first one.  And 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 like a long code like this it will share most of the significant  digits or if you're going to build three name code then it has to share the first word.  Now as far as memorizable 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 Google plus code equivalent  of that or this is the three, what 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 this written in pearl, it's on cpan  and you use it in that way.  Just embed it in 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 this nice special about one gigabyte memory and one CPU but  it can only handle about 100 requests per second if you do more than 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 borders.  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 they use a skip-list data structure to name each one.  So for example you can short of them, let's call them geopolygons 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 the sense squares or pentagons  or hexagons or whatever, 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 state is 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 is a place in Tirana where I'm from Albania, it's called Krap.  So you will have a location called Brax, 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 a lot of, 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 ten 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 and coding  per se.  I don't really care much about building a geohash but I wanted to build a faster reverse  geocoding algorithm.  So point and 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.  So 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 non-photon numeric string  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 Zordr curve to get  this overlapping arrangement and there are no discontinuities even at the 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.  I have another 15 minutes which is great.  So basically you can solve this problem on the data line and this extantable.  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 geo names and open street map 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.  It is possible, I thought about doing it before I came to this presentation to just get the  geo names, alternate names field and to just produce a couple of options but I will let  other people tackle the problem if they feel so inclined and as far as error correction  you could also, what I have built is, see each of these 150,000 words has a certain  added distance both on audio in the audio sense and the character sense from each of  every other ones.  So basically I picked my geo names 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.  Alright 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 hoop 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 and not to  use it but 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 I'll have further ado, I think I have a few minutes  I just before I go to questions there is a website I put up, well it defaults to that  but it 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, ah, Langkou, at least it's not crap, well crap is the next meter  of, so if I was like sitting, I don't know how geocaching 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, 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 control  copy instead of latitude and longitude you can also use like the number of the location  oops, oh wait, I'm trying to copy and paste this thing, alright, ah, not having any luck,  I forgot how to copy and paste, there you go, so if you add a.json in the end especially  many JavaScript programmers like this, you just get that and ah, or you can put the 3G  name version here, so like this and it's the same thing, so that's it for now, ah, let  me know if you have any more questions.  We have about seven minutes left, 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 this number  sequential so let's say two latitudes and longitudes that are close together here and  the chair over there would have very close geo numbers like different by one number or  two.  Right, and is that a part of this or is that a generic or is it part of your open source?  It's part of the open source, yeah, yeah, I mean the Hilbert curve is open source, there's  other implementations of Hilbert curve that could do exactly the same thing.  Anyone else?  Please, why do you want a unique geo curve for your location?  Why do I want a unique?  I don't know, I thought it would be, right, as a mathematician I think one to one functions  are better than things that are less predictable than that, like I want to be able to say that  I'm at exactly this unique code as opposed to I could be 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.  Anyone else?  Is it might be you?  Sorry?  Is it might be you?  Oh yes, I can probably show you.  See geo code.xyz, it's a reverse geo code basically, this is why I built it.  So right now if I go to cloud flare, there is about, well no, no, this one, there is about  100 million requests for months on this API, but people don't usually use it for the geo  code themselves, they just want to use a reverse geo code engine for the fleet tracking  for things like that.  I think the geo hars 36 algorithm has a feature that they include elevation as well.  I'm looking to 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.  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 latitude.  So it's totally possible, like 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 will be a little bit longer.  That's all.  No, Hilbert curve is much better than the Z-order curve, which is what the geo hash  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.  But from what I've seen, and I use two different, I use both Z-order and Hilbert curve 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.  So as far as reverse geocoding goes, I don't think I'll miss anything by using them both  in superimposed and challenge.  Thank you.  Q. Are there mixes with seasonality, meaning the tides or the elevation of snow or things  like this within the data in terms of how to...  The tides?  Q. The tides, yes.  Sometimes there is land and sometimes there is not, because of the tides, because of the  tides.  Q. I see.  See, I haven't really bothered much with taking into account temporal displacements.  Basically, I just get latitude and longitude and convert it to 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.  Q. Since you're using the first part of the code, is there a location inside of that?  It's always like that, for example...  That is a very good question.  And you're right.  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...  Q. Okay, that was the last question.  Once again, thank you very much.  Q. Thank you.  Q. Can I ask you a question?  Q. Can we get this presentation done?  Q. Yes.  Q. Is Fisario present?  Q. Yes.  Q. Is Fisario present?  Q. Hi.  Q. I'm from Europe.  Q. I'm from Cambridge, Canada.  Q. I'm from Cambridge, Canada.  Q. Sorry?  Q. Can you give me your presentation?  Q. Yes.  Q. Yes.  Q. Yes.  Q. Yes.  Q. Yes.  Q. Yes.  Q. Yes.  Q. Yes.  Q. Yes.  Pahrt, permit.  Mbappata.  Here is the delay.  OK.  OK.  So, let us move on.  So, let us move on.  Pahrt, you introduced yourself.  After the 2th quarter of this program, what led you to such a strong union that G ak  Or Kilbis was given to you here on the drivetrain?
3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__0_179.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__180_1139.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__1140_2531.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__2532_3635.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__3636_4415.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__4416_6683.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__6684_8747.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__8748_9491.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__9492_10835.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__10836_14603.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__14604_15131.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__15132_15215.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__15216_15419.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__15420_15623.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__15624_16475.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__16476_16607.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__16608_17555.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__17556_18047.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__18048_18971.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__18972_19547.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__19548_20279.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__20280_24107.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__24108_25391.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__25392_29891.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__29892_29999.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__30000_33335.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__33336_36395.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__36396_36731.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__36732_37043.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__37044_37595.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__37596_37895.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__37896_40967.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__40968_41291.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__41292_41339.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__41340_41447.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__41448_41543.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__41544_43067.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__43068_43235.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__43236_44471.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__44472_44855.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__44856_45047.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__45048_45131.png 3Geonames_org_An_open_source_Geocoding_system_for_the_simple_communication_of_locations_with_a_reso__45132_45248.png