There are more and more use cases for location-based applications. Allied Market Research predicts this segment should reach $318.64 billion by 2030, with the projected compound annual growth rate (CAGR) of 24.3% between 2020-2030. This data shows that location-based service apps are increasingly becoming a necessity for many businesses. It’s no wonder that many of them are looking for ways to optimize the cost of GIS software development.
Relying on ready-made APIs offered by popular map providers such as Google Maps or Mapbox can prove to be very costly for companies that build robust location-based solutions or those that scale up quickly, if not faster than expected. We learned this while working with Trans.eu – one of the leading logistics platforms in Europe and Asia.
In this article, I will explain what led us to choosing the open-source OpenStreetMap to build Trans.eu. Let’s start with a little bit of background on the platform itself.
Trans.eu is a web-based logistics marketplace, concurrently used by over 62 000 companies with nearly 6 mln location-based APIs requests on a daily basis. We started building it back in 2005, so it has grown and evolved to a great extent over the years.
The logistics industry has somewhat different needs than, let’s say, users of on-demand apps like Uber or DoorDash. Freight forwarders often navigate maps using postcodes rather than addresses. In Trans.eu, we knew we needed to give them an opportunity to search through a large database of geospatial information for specific coordinates.
To this end, we built a web application that includes (among others functions):
Forward and reverse geocoding with autocomplete
Routes creation module
Routes optimization algorithms
Custom geodata layers
We could have used Google Maps APIs to build the app, but considering what we wanted to achieve and our large user-traffic that surpassed the free tiers within a day, it would have cost us at least 420 000 USD per month – stemming only from the map-related API requests. Let’s take a look at what exactly contributes to this total cost.
Map APIs usage pricing: Google Maps
Below, I’m presenting the usage costs for the selected APIs at 5,8 mln requests per day (the actual usage in Trans.eu). The totals were calculated using the official pricing breakdown offered by Google Maps. We are aware that just with our daily usage, we already go beyond the scale of the offer, so we presume we could have negotiated a discount, but that would still generate hefty usage bills.
As you can see, the total cost for building a logistics platform with a large volume of traffic on ready-made APIs is immense. We found we wouldn’t be able to create a sustainable business model for Trans.eu with the commercial solutions available. Opting for OpenStreetMap was the best option in our case. In fact, OpenStreetMap also gave us additional benefits.
This was important to us because we built the visual layer for Trans.eu with OpenStreetMap as well. We wanted to avoid a situation in which the search function works for the coordinates, but doesn’t display them on the map (or the other way round: something visible on the map cannot be found in the search field). That could have happened if we used a different API provider.
Greater influence on the app behavior
As mentioned earlier, in the logistics industry, operators often search their destination through postcodes. We wanted to build a custom geocoding service for that. Users can simply type in, e.g. PL5 4RL, which is a typical postcode format in the UK, to find the relevant area.
We also wanted to leave the door open for additional data inputs. This flexibility is a great added value that allows businesses to freely expand the tools in the directions they want. We are currently working on marking warehouse entryways so that truck drivers can be directed to the exact point where they can drop off the cargo.
Are there any downsides to using OpenStreetMap? There’s no point in beating about the bush here, of course there are:
It’s an open-source solution, which means that errors can occur. Sometimes data can be missing when somebody deletes something by accident, or the data may be slightly inaccurate. This requires companies that use OpenStreetMap to monitor the data for quality. That can be outsourced, but generates additional costs.
We secured ourselves against such errors by implementing a custom-built mechanism for updates (OpenStreetMap releases an update package daily for implementation by users), but that took us a while.
It requires ongoing maintenance support and generates additional bills.
We had to custom-build Trans.eu around OpenStreetMap from scratch, which took us a long time and cost us a lot of money as well. However, weighing the pros and cons, we decided that eliminating the monthly usage bills afterwards will be more profitable for us in the long run.
Cutting map usage costs with OpenStreetMap
What are the conclusions here? OpenStreetMap is a good map data source and it can help you eliminate the bills for map APIs usage. Nevertheless, building an app using the open source data will require additional investment of both time and money in custom development and maintenance. If you're oriented at software development cost optimization, you should take a look at the relevant pricing options and estimate the expected costs. With that, you would be able to determine the threshold beyond which using paid APIs doesn’t pay off for you. As long as the infrastructure, custom development and maintenance costs won’t surpass the cost of usage volume, OpenStreetMap will yield positive ROI in the long run.