About this talk
In this talk, Mikhail Chichulin, a senior team lead at Auto1 Group, discusses the implementation of a self-hosted Geographic Information System (GIS) that significantly reduced their reliance on the Google Maps API, lowering costs by approximately 50%. He explains that Auto1, which specializes in buying and selling used cars, shifted from a manual logistics process to an automated system to schedule deliveries for their own trucks. The speaker outlines the challenges faced with Google Maps' limitations on data storage and real-time information, prompting the search for alternatives. By utilizing OpenStreetMap data and incorporating various tools such as ORS for routing and Pelias for geocoding, they established a robust solution. Although the system has limitations regarding data quality and requires periodic updates, it has been beneficial for their logistics operations and data analysis.
Full transcript
Morning. Do you hear me? Cool. So, [snorts] once again, good morning. My name is Mikhail Chichulin. I'm a senior team lead at Auto1 Group in Berlin. Uh I work in there for more than 9 years and most of this time, since senior engineer, I was working with logistics or in charge of logistics. So, before we continue, I will briefly introduce the topic. I will talk about how
we introduced self-hosted GIS, geo informa- geo informational system, uh cut our Google Maps API bills by almost a half. So, first of all, who have heard about Auto1? Okay, a few. So, let's make some recognition. Maybe you did. uh we buying and selling used cars. Maybe you have heard about Wirkaufautos, which is the same as Wirkauf and uh Dein Auto in Germany. This is the brand where
we buy used cars from individuals. Then, we try to sell them all in Auto1 Group, auto1.com. Uh we selling them to professional dealers and uh set of the cars we sell to uh private people with Autohero. So, we moving cars around and some stats. Basically, in 2025, we sold more than 800,000 cars in more than 300 markets and we use more than 300 logistic partners to do
it. It means what we delivering cars car with a lot, but also our logistics is mostly about choosing the best partner to deliver set of cars from A to B. And it was so for years. We didn't need much from GIS. We only draw maps here and there. But things changing and we start to buy those guys. It's a trucks to deliver auto here cars to the
buyers to their homes and it's our own trucks. We don't allow third parties to operate them and we need to schedule deliveries for those trucks and we need to put them we need to arrange schedules of every single driver. How to do it? Originally, when it was very few trucks, operators just go to a special uh page on back office, uh put the address there where to
deliver this page calculated round trip time. Based on that, operator went to the driver's calendar and put the delivery Not very complicated and well, very manual, I would say. But with time, we needed to actually automate it. And to automate it, you need to save this round trip somewhere and here is a surprise. You cannot do it with Google Maps because Google Maps terms and condition doesn't
allow you to to store this information. It's a violation. And we started to look for alternatives. So, here I wanted to show you a table where we considered different providers, but this table was made in 2023 when it was all happened. And I believe it's a bit outdated today. instead of that, I would say that we tried major providers including TomTom. And we decided to try another
approach. We tried self-hosted solution based on OpenStreetMap's data. Why? Because there are no limits for how many calls we can make. There is no let's say restriction for saving the data. And also our business told us that if it wouldn't be perfect, it's still okay because we actually don't deliver that many cars a day. They don't need real-time info. So, jumping to the results. I can say
that it worked out for us pretty well. In 2025, we estimated that we saved something like 50% on overall Google Maps API costs. We also enabled completely new use cases for data analysis. And we are pretty happy with how solution worked. We integrated it with most of our internal clients right now. About running cost, it's not super expensive for us. We run two almost identical copy for
QA and production. And they pay for themselves. It actually means that we uh only spend on them something like 5 to 10% from monthly savings on Google Maps. >> [snorts] >> And we don't have anyone full-time supporting this solution. We have people looking at data, of course, but it's kind of part of their normal job. They're doing something else in parallel. And also about the usage, we
didn't replace completely Google Maps. We're still driving maps here and there with Google Maps, but we almost completely replaced geocoding and driving time calculation. And we still use Google Maps as a fallback for about 5% of the cases when we cannot get a quote with OpenStreetMap. So, now I hope it's still interesting and I want to share some technical details, not that much, but yeah, let's look.
So, first of all, maybe most interesting for people who will introduce it, it's how the lens landscape looks like. Let's start from the data. So, as a very base of it, we have OpenStreetMap. It is Wikipedia of the maps, so I I can say, and everyone probably heard about On top of it, we use two so-called gazetteers, GeoNames and Who's On First. gazetteers are catalog of uh
geographical names, like for instance, Amsterdam, Rotterdam, and so on, and matching them to coordinates. From the software point of view, for routing, there is OSRM, Open Source Routing Machine, which is default for openstreetmap.org. We decided against using it because it's C++, it's very high-performant, but we don't have C++ engineers in our company, so hard to support. Instead, we decided to use ORS ORS. It's a similar thing
written in Java in Heidelberg University, Germany, and it works pretty well for us. We configure it a lot for our needs, and it's there, it's just working. For geocoding, there are many solution, primary Nominatim, which is again the same issue, C++, and we decided against using it really. Another reason for this, it doesn't support anything like auto complete uh for addresses, which we want to have eventually.
Instead, we decided to use uh Pelias. Pelias, it's not JS plus Docker plus Elastic Search. Looking from now, I would maybe make another choice because since 2023, Pelias become not very actively maintained. But, it's there and it's working. Let's look at how it's organized inside. So, all this OpenStreetMap based software we put into Kubernetes cluster, which is completely isolated from my internet and even from our own
cloud. it's running there, and we have geo service, which is a facade API, allowing us to go there to the cluster and providing our clients with most basic information uh they need. So, basically, if you like driving time, you will get driving time. If you like driving distance, you will get driving distance, no overhead. Uh also, geo service takes care about uh fallbacks. It's basically knows when
to cache data, when not to cache data. It informs the clients about it, and it cache data by itself. So, basically, we probably save a bit more than 50% if you would be very accurate and know how much we would really spend without it. About the process how it was done. So, we spent something like 3 months building this solution. First, about 2 months we spent on
assessing it. Uh our DevOps engineer introduced the first installation. I was spending a lot of time building Google spreadsheets uh comparing data between Google Maps and our own knowledge and this new provider and understanding how good or bad is it. >> After 2 months, we decided that it's okay, and we can try it. Business say so, we build a pilot pilot project. Pilot project went directly to
this OpenStreetMap software. We build it for only 2 weeks or something like that. We put it on production and after that business tried for maybe a week or two. They told us that it's okay. They can use it. And we spent more 3 weeks building the facade and uh let's say releasing it. Moving the pilot project to that facade as well. Since then we're integrating we're integrating
till now. By the end of 2024 we finished with all internal logistic use cases which were not a lot not so many but it still took time. And we also kind of polish the project. by the end of 2025 we finished with all internal geocoding and driving distance use cases and we have our let's say numbers we saw cutting the cost by half. Also fun fact was
uh our account manager from Google start to recommend our solution to our our inter in other clients inside AutoZone. Uh and when this presentation was made I checked the stats and I see that it's uh actually traffic grew uh more than 100% year over year. So our data analysis uh start to use it and probably in 2026 we will save even more. Okay, it was good part
of it. Let's look at the problems. Of course it's not all that uh very nice and green and shiny. It's still not very maintain maintenance intensive. We don't spend that much time supporting it. We don't have as I already said any full-time engineers looking at this. But from time to time we have support tickets. Most of them about quality of the input data. Input I mean input
from the client. And yeah. Only real pain point is about updating it. Updating takes hours and it's not very involved job, but you still need to look at this from time to time and it's also sometimes need restarting. Good thing it's our devops engineers doing. Not me. Also quality of the data is not really let's say stable between countries. For instance, in countries like Netherlands and Germany
it's rather good. In Southern Europe not all the time. It also differs between industrial rural areas and metropolitan areas. Where people live it's much better. Where people not live not so much. And of course it doesn't have real time data, not traffic data and road closures and so on. You will only know about them if someone put them there and you update after that. So if it's
something like for 2 days, you probably won't know about it. So not very suitable for real time routing. And why we still need Google Maps even for geocoding? Because if you have vague addresses like street name, number, maybe not without postal code and something after that like apartment number or what you need to turn the corner to deliver it. It may be confusing for periods or open
street map solution. You will probably go to Google Maps again, and Google Maps will give you some coordinates. But, here I need to say that in such cases, even Google Maps not always doing very good job, and it may start pointing you to Ecuador instead of Spain, which happened to us a couple of times. Yes, so you need to be careful. And, it might be what you
won't have, uh, up-to-date and complete data about stuff like ferries. And, if you operate in complex terrain, like, uh, I'd say, islands, maybe in Greece, it will be a bit tough to use OpenStreetMap. I'm already going to finish, and [snorts] instead of conclusion, if you have well-structured address inside your system, if you also find uh, operating in generalized areas, like towns, villages, postal codes, maybe, >> and
if you find this, uh, driving time and distance, uh, estimation in hours and kilometers, it may work out for you pretty well. Also, on top of it, I would say that if you want to spend money in it, you need to have some money to spend, and if your bills of, uh, commercial providers already in thousands, it may be interesting. But, before that, maybe you will spend
more operating in it. And, in all other cases, when you have, for instance, user input, uh, and you don't structure it too much, if you have complex terrain, if you have, uh, if you need really real-time with traffic data, and minute accuracy estimation of, uh, delivery time, I would say it might be tricky. So, in this case, I would advise better maybe consider commercial providers. It will
work better for you. And yes, that's basically it. Thank you very much for coming. And if you have any questions, I guess it if you catch me after this talk off stage. Thank you once have a great day.
