Working with geodata in Go
Minkin, Andrew
I'm going to talk about some features that we've done recently for one of ourclients "Namba Taxi": * Show nearest available drivers in our mobile app and moving single car on map * Help our partner build traffic jam map based on our data In my talk I want to reveal: * How we collect GPS tracks from driver apps and save mobile traffic * How we implemented lightweight network interaction between the driver app and backend services * What solutions were used for high performance on backend * How we store GPS tracks for client history * How animation of car works inside the client app * How to perform monitoring and ensure that service works fine * Geocoding problems in developing countries with lack of maps data
 Yeah, it's green. Can I start now or you announce me? I don't know what to do. 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 in geospatial dev room, 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 a mad devs.tio 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, driver can took it from mobile application. Client sees the taxi and goes to the destination point and at the end the order is finished and client can see 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 or for 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 client can track driver location and first challenge that we faced was lake of data. For instance we get a new location from driver in 15 seconds and we can't just decrease the data interval because when driver's mobile application sends data to us it gets status of current order, next order and is there any other. And our first try was simple in shipping. We tried to make request, then we save coordinates, make another request and then try and animate the car. As you can guess there are problems with it, you can't animate car properly and it moves through fields, forests, quarters and it looks like this but it doesn't work. As a solution of the problem we use open street map routing machine for building roads and our algorithm improved and we have same amount, we make request, send coordinates, save, send coordinates to our backend, build road, we have SRM and return to the client app and animate the car. But we faced with another problem with one way roads, for instance driver stays at the red point on the crossroad but his device has bad accuracy on location of it, he stays on the side of the crossroad. Get this 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 distances less than 20 meters. After several days of testing we decided to release our applications and go to the next iteration because several things need improvements. First is trip cause calculations were on the driver's side. At this point we have, we save server resources because we don't send useless request but the second point we have only one trust point is driver mobile application and also we realize that the send one track per 15 seconds is too less and lots of customers don't get site 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 is the task that we need to solve and I want to say some words about saving 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 site of the city to another site 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 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 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 mobile application, 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 road. 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 geocoding 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 line drivers and use these storages to store data, seems no expedient and we decided to build our own memory storage and first of all we need geoindex to store data and we watched for two geoindices, KD3 and R3 and we had requirements for geoindex and first we need to search nearest points and 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 point over KD3 but we won't reinvend 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 LRU 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 search 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 RADIES we check and validate data we try to set driver to storage. If it doesn't exist we initialize LRU 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 and refactor it 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 end points 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 user slash status and bots because first three items are obvious. So usual slash status returns sometimes since server has started HTTP start this counters and total requests processed by the server and 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 server, sensors we get nearest drivers with rows, we animate each car and 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 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 own database and we decide to go build our own geocoder and in our geocoder we need to support this search for much, 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 joint ICs with similar scheme and we use OpenStreetMap data and drivers 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. So that's all. Thank you. Yes. The final application is already being used now isn't it? Yes. So 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. So yes. You mentioned you use Elasticsearch for the geo search. Did you consider to use Redis for that? No. We watched for Elasticsearch 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 and C and C and NAC and it's 6C bytes only for connection. And UDP you send only data crimes and you save at least 60 bytes because you don't need to. Yes. Yes. You mentioned that you used OpenStreetMap data for showing the map. If your own database of the app is 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 provide back, you don't deliver inputs to OpenStreetMap to make that better for everyone using it? Because 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. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
 Yeah, it's green.  Can I start now or you announce me?  I don't know what to do.  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 in geospatial dev room, 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 a mad devs.tio 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, driver  can took it from mobile application.  Client sees the taxi and goes to the destination point and at the end the order is finished  and client can see 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 or for 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 client can track driver location and  first challenge that we faced was lake of data.  For instance we get a new location from driver in 15 seconds and we can't just decrease  the data interval because when driver's mobile application sends data to us it gets status  of current order, next order and is there any other.  And our first try was simple in shipping.  We tried to make request, then we save coordinates, make another request and then try and  animate the car. As you can guess there are problems with it, you can't animate car properly  and it moves through fields, forests, quarters and it looks like this but it doesn't work.  As a solution of the problem we use open street map routing machine for building roads and  our algorithm improved and we have same amount, we make request, send coordinates, save, send  coordinates to our backend, build road, we have SRM and return to the client app and  animate the car.  But we faced with another problem with one way roads, for instance driver stays at the  red point on the crossroad but his device has bad accuracy on location of it, he stays  on the side of the crossroad.  Get this 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 distances less than 20 meters.  After several days of testing we decided to release our applications and go to the next  iteration because several things need improvements.  First is trip cause calculations were on the driver's side.  At this point we have, we save server resources because we don't send useless request but  the second point we have only one trust point is driver mobile application and also we realize  that the send one track per 15 seconds is too less and lots of customers don't get site  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 is the task that we need to solve and I want to say some words about saving  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 site of the city to another site 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 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 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 mobile application, 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 road.  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 geocoding 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 line drivers and use these storages to store  data, seems no expedient and we decided to build our own memory storage and first of  all we need geoindex to store data and we watched for two geoindices, KD3 and R3 and we had  requirements for geoindex and first we need to search nearest points and 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 point over KD3 but we won't reinvend 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 LRU 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 search 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 RADIES we check and validate data we try  to set driver to storage.  If it doesn't exist we initialize LRU 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 and refactor it 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 end  points 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 user slash status and bots  because first three items are obvious.  So usual slash status returns sometimes since server has started HTTP start this counters  and total requests processed by the server and 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  server, sensors we get nearest drivers with rows, we animate each car and 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 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 own database and we decide to  go build our own geocoder and in our geocoder we need to support this search for much, 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 joint ICs with similar scheme and we use OpenStreetMap  data and drivers 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.  So that's all.  Thank you.  Yes.  The final application is already being used now isn't it?  Yes.  So 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.  So yes.  You mentioned you use Elasticsearch for the geo search.  Did you consider to use Redis for that?  No.  We watched for Elasticsearch 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 and C and C and NAC and it's 6C bytes only for connection.  And UDP you send only data crimes and you save at least 60 bytes because you don't need  to.  Yes.  Yes.  You mentioned that you used OpenStreetMap data for showing the map.  If your own database of the app is 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 provide back, you don't deliver inputs to OpenStreetMap to make that better  for everyone using it?  Because 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.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.
Working_with_spatial_data_in_Go_0_59.png Working_with_spatial_data_in_Go_60_1403.png Working_with_spatial_data_in_Go_1404_2927.png Working_with_spatial_data_in_Go_2928_3203.png Working_with_spatial_data_in_Go_3204_4103.png Working_with_spatial_data_in_Go_4104_4355.png Working_with_spatial_data_in_Go_4356_4883.png Working_with_spatial_data_in_Go_4884_8687.png Working_with_spatial_data_in_Go_8688_11651.png Working_with_spatial_data_in_Go_11652_15359.png Working_with_spatial_data_in_Go_15360_18311.png Working_with_spatial_data_in_Go_18312_18947.png Working_with_spatial_data_in_Go_18948_26759.png Working_with_spatial_data_in_Go_26760_32543.png Working_with_spatial_data_in_Go_32544_32591.png Working_with_spatial_data_in_Go_32592_32687.png Working_with_spatial_data_in_Go_32688_32747.png Working_with_spatial_data_in_Go_32748_32795.png Working_with_spatial_data_in_Go_32796_32867.png Working_with_spatial_data_in_Go_32868_32927.png Working_with_spatial_data_in_Go_32928_32987.png Working_with_spatial_data_in_Go_32988_33035.png Working_with_spatial_data_in_Go_33036_33119.png Working_with_spatial_data_in_Go_33120_33167.png Working_with_spatial_data_in_Go_33168_35243.png Working_with_spatial_data_in_Go_35244_35291.png Working_with_spatial_data_in_Go_35292_37607.png Working_with_spatial_data_in_Go_37608_37728.png
Yeah, it's green. Can I start now or you announce me? I don't know what to do. 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 in geospatial dev room, 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 a mad devs.tio 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, driver can took it from mobile application. Client sees the taxi and goes to the destination point and at the end the order is finished and client can see 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 or for 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 client can track driver location and first challenge that we faced was lake of data. For instance we get a new location from driver in 15 seconds and we can't just decrease the data interval because when driver's mobile application sends data to us it gets status of current order, next order and is there any other. And our first try was simple in shipping. We tried to make request, then we save coordinates, make another request and then try and animate the car. As you can guess there are problems with it, you can't animate car properly and it moves through fields, forests, quarters and it looks like this but it doesn't work. As a solution of the problem we use open street map routing machine for building roads and our algorithm improved and we have same amount, we make request, send coordinates, save, send coordinates to our backend, build road, we have SRM and return to the client app and animate the car. But we faced with another problem with one way roads, for instance driver stays at the red point on the crossroad but his device has bad accuracy on location of it, he stays on the side of the crossroad. Get this 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 distances less than 20 meters. After several days of testing we decided to release our applications and go to the next iteration because several things need improvements. First is trip cause calculations were on the driver's side. At this point we have, we save server resources because we don't send useless request but the second point we have only one trust point is driver mobile application and also we realize that the send one track per 15 seconds is too less and lots of customers don't get site 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 is the task that we need to solve and I want to say some words about saving 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 site of the city to another site 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 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 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 mobile application, 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 road. 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 geocoding 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 line drivers and use these storages to store data, seems no expedient and we decided to build our own memory storage and first of all we need geoindex to store data and we watched for two geoindices, KD3 and R3 and we had requirements for geoindex and first we need to search nearest points and 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 point over KD3 but we won't reinvend 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 LRU 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 search 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 RADIES we check and validate data we try to set driver to storage. If it doesn't exist we initialize LRU 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 and refactor it 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 end points 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 user slash status and bots because first three items are obvious. So usual slash status returns sometimes since server has started HTTP start this counters and total requests processed by the server and 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 server, sensors we get nearest drivers with rows, we animate each car and 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 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 own database and we decide to go build our own geocoder and in our geocoder we need to support this search for much, 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 joint ICs with similar scheme and we use OpenStreetMap data and drivers 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. So that's all. Thank you. Yes. The final application is already being used now isn't it? Yes. So 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. So yes. You mentioned you use Elasticsearch for the geo search. Did you consider to use Redis for that? No. We watched for Elasticsearch 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 and C and C and NAC and it's 6C bytes only for connection. And UDP you send only data crimes and you save at least 60 bytes because you don't need to. Yes. Yes. You mentioned that you used OpenStreetMap data for showing the map. If your own database of the app is 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 provide back, you don't deliver inputs to OpenStreetMap to make that better for everyone using it? Because 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. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
Andrew Minkin and today I'm going to tell you at source project as much as I can and one of my becomes available to drivers, driver can took it have SRM and return to the client app and animate we have lots of problems with GPS module on the from the driver location, session and trip perform search of driver for mobile application, Last locations to perform search of nearest service and we implemented these end points and at that point we were ready to deploy it and I to maintain it and I want to tell you more about developing countries. So we have lack of data build our own geocoder and in our geocoder we used OpenStreetMap data for showing the map. If