 Can I start now or you announce me? I'm okay. Hey, my name is Andrew Minkin and today I'm going to tell you at least two stories from my work experience. And my talk is on Geospatial Devrooms, so I should speak more about Geodate and less about Go. So who am I? How can I be useful for you? I've been working for MEDevs.io for the last five years and now I'm Tim Liza. And I try to contribute to open source project as much as I can. And one of my favorite project is Meshbert. With Meshbert you can build virtual private networks between your data centers, virtual machines or Docker containers. So I'm from Bishkek. It's the capital of Kyrgyzstan and it's small city with population around 1 million people. And for that 1 million people we have around 100 taxi services. One of our clients is a number taxi, is a leader on the market, and it processes more than 6,000 orders and has more than 600 online drivers and around 500,000 of clients. And 500,000 of clients is actually half of our city. So what's a taxi? First of all it's our clients, client books taxi via SMS, voice or IPTV or mobile application. And the order is processed by an operator and once it becomes available to drivers, the driver can took it from mobile application. The client sees the taxi and goes to the destination point and at the end the order is finished and the client can see a report on the mobile application or on the website and also the managers can do the same. And this workflow is automated by our backend systems and the average response time for drivers is 20 milliseconds and for operators 2.5 milliseconds. So first study is about simple in-memory data storage for geodata and it starts from graduation work of our mobile developer. The work topic was driver application for taxi service and in the application he has animated the car and it looks like these body animations don't work. So we thought why not using this on the screen where the client can track the driver location and the first challenge that we faced was lake of data. For instance, we get a new location from the driver in 15 seconds and we can't just decrease the update interval because when drivers' mobile application sends data to us it gets status of current order, next order, and either any other. And our first try was simple in shipping. We tried to make a request, then we save coordinates, make another request and then try to animate the car. As you can guess there are problems with it. You can't animate the car properly and it moves through fields, forests, quarters and it looks like this but it doesn't work. As a solution to the problem we used OpenStreetMyProvoting machine for building roads and our algorithm improved and we have same amount, we make request, send coordinates, save and save, send coordinates to our backend, build road via SRM and return to the client app and animate the car. But we faced with another problem with one-way roads. For instance, the driver stays at the red point on the crossroad but his device has bad accuracy and location of it. He stays at the side of the crossroad. Get these coordinates, send it to SRM and it builds a legit road return to the app and it looks ridiculous because marker moves so fast and as a solution of the problem we just check distance between two points and not building road for a distance less than 20 meters. After several days of testing we decided to release our applications and go to the next iteration because several things needed improvements. First is the trip cause calculations were on the driver's side. At this point we have, we save server resources because we don't send useless requests but at the second point we have only one trust point, it's a driver mobile application and also we realize that send one track per 15 seconds is too less and lots of customers don't get sight of our feature because I know not so many people who can look at the screen where there's nothing going on for 15 seconds. And also we have lots of problems with GPS module on the driver's side and as for them first two are associated with the device and in our country we use brand new cheap Chinese device for taxi service and so we need to handle this too. And here are the tasks that we need to solve and I want to say some words about sending mobile data why we need it because in our country we have cheap receipt for taxi service and internet cost is too high. For instance you can get from one side of the city to another side of the city just for two years. It's like bus in Brussels or metro in Paris and if we save at least 100 bytes per second then we save around 2000 of dollars at company scale. So what's the track? Track is composed from the driver location, session and trip information I mean the order ID and trip cost and we decided that one track should be less than 100 bytes and we started to search transport protocol for it and we watched for several protocols and for us the ideal option was UDP because of these facts and I know that in some countries for mobile networks UDP can be blocked but for our case it was okay. So we chose UDP and for data serialization we chose protocol buffers because it's so efficient on little data and as you can see the nearest competitor is heavier twice. So what do we have? We have 40 bytes of payload plus 20 bytes of IP headers that equals 40, 62 bytes per track and we solved the problem and when we get data we need also to store it and the second part of the story is data storage and we need to store driver session that we give up on login and to identify driver. Cab number to perform search of driver for clients mobile application order ID and trip cost to save trip information on the server side last locations to perform search of nearest drivers and then last locations to build a route. So in number taxi we use Percono server to store all the data we store drivers, fares and everything in Percono we use ready server for caching purposes and elastic short for Joe coding and in the second part of the story I tell you more about how we use it. As I mentioned above we have more than 600 online drivers and use these storages to store data seems no exponent and we decided to build our own memory storage and first of all we need a geoindex to store data and we watch for two geoindices KD3 and R3 and we had requirements for geoindex and first we need to search any response it must be balance tree we watched on KD3 it looks like this but it doesn't fit our needs because it's on balance tree and it can search only one nearest point yes we can implement K nearest pointer over KD3 but we won't reinvent the wheel because R3 already has it so for our storage we chose R3 and for Go programming language you can get it there so going next in very if and not ideal world and drivers can just turn off your phone and you need to invalidate some data and drivers of all can be ideal for us I mean that they have bad internet connectivity or the reasons that you can see on the slide and to solve the problem we need an experiment mechanism to invalidate drivers and show only actual information to our operators and also we need a real data structure for storing coordinates because it's useful you only initialize data structure for any items and when you try to add new item when storage is already filled you remove least recently used item and add a new one so here is the final storage architecture that we use we store all data in memory using R3 to perform search of nearest drivers and also we use two maps for storing drivers and perform search by cab number or by session so here is the algorithm on back end we try to get data by UDP we try to get driver from the storage if it doesn't exist we get some driver information from radius we check and validate data we try to set driver to storage if it doesn't exist we initialize LREU and finally we update R3 and we use Go programming language to implement this because of these facts and when we discovered Go we fell in love with it we factored all our microservices written on Python and Ruby to the Go programming language and also we need HTTP IP to integrate to our service and we implemented these endpoints and at that point we were ready to deploy it and I want to tell you but before we need to know how to maintain it and I want to tell you more about usual slash status and bots because first three items are obvious so usual slash status returns sometimes since server has started HTTP status counters and total requests processed by the server we use bots to emulate our workflow for drivers and clients and they are running Morocco or Congo to prevent influence on our customers so for a client mobile applications looks like this we get client location from the servers we get nearest drivers with rows we animate each car and the update interval is 15 seconds for the client application so that's the main slide of the first story and the second story is about challenges with geocoding in developing countries so Bishkek is a city with small quarters and people book taxi to intersections very often so also we have lack of data from Google, OpenStreetMap and whatever provider we have and also we can't trust GPS data from our drivers because as I said above we have bad devices so we use OpenStreetMap data for our purposes because it's more detailed in our country and also we have on database these addresses that collected from our drivers so we need to find a way how to merge OpenStreetMap data with our on database and we decide to build our own geocoder and in our geocoder we need to support these search formats for instance user can build query by street plus house number intersection, name of institution, point of interest micro district plus house number or micro district plus street plus house number and also we need to support different we need to support synonyms because we use shortest version of names and we chose elastic search because of ease of use and we created addresses slides to combine two joined ICs with similar scheme and we use OpenStreetMap data and drivers data populates from our drivers and improves search quality so you only need to run slash Ariadna update and you may go and drink coffee and when you drink coffee Ariadna does this stuff so here is a short list of features and you can get it there so thank you for your patience if you have any questions that's all yes the final application is already being used now isn't it? yes the first statistics you gave were about user service application or the general use of the taxis or my question is actually how many people are using it right now? you mean the clients or drivers for the clients it's around 6,000 people per day and for drivers it's around more than 600 online drivers you mentioned you used elastic search for the geo search did you consider to use Redis? no we watched for elastic search a year ago and I know that Redis now have some geo features but when we try to build our geo code we weren't known about Redis I mean that's about the geo features so yes for TCP you need to do a handshake you need to send C in the NAC and it's 60 bytes only for connection and UDP you send only datagrams and you save at least 60 bytes because you don't need to... yes you mentioned that you used OpenStreetMap data for showing the web in your own database to merge them is it merged every time or did you merge the addresses into the OpenStreetMap database? so we use only... from the OpenStreetMap we use only data and we update our index once a day so you don't deliver inputs to OpenStreetMap to make that better for everyone using it because we... yes now we have plans to do it but now we weren't sure that our data will be helpful because of addresses formats and that's all okay, thank you