Blog

You pay for every route and every address. Do you have to?

How we replaced a paid routing API with our own open-source engine in transport, and where else it works.

One of the transport and logistics operators we work with was paying over €1,000 a month for truck routing. Not for any special feature, but because its quoting and planning system asked an external API for a route every time someone changed a pickup point, the order of stops or a vehicle.

A bill like that has one defining trait: it grows with your business. More quotes, more plans, more changes means more requests. The better you do, the more you pay for what is essentially a calculation on data that is public anyway.

Where the bill comes from

Paid map APIs charge per request, usually per 1,000 requests beyond a free quota. A system that plans routes on the fly sends a lot of them:

  • every quote needs at least one route,
  • every change to a plan recalculates routes,
  • optimising several vehicles needs whole matrices of travel times.

Simple arithmetic, requests × price per 1,000, shows that at tens of thousands of requests a month the cost becomes a real line in the budget.

What we did

Instead of paying per request, we set up our own routing engine: Valhalla, an open-source routing engine built on OpenStreetMap data. It runs as a single service in the same cluster as the rest of the system. The application queries it the way it used to query the external API, so the code change was small: a new client, a result cache and error handling.

The outcome:

  • no per-request fees: the cost is running one small service,
  • no vendor dependency: nobody can change the price list or retire an old API version,
  • data stays with the client: the coordinates of cargo and customers never leave their infrastructure.

Numbers from practice

We measured this in production, not in a lab:

  • about 65 ms per route leg, and a repeated leg is served from the cache in practically 0 ms;
  • ranking 15 appointment slots by actual driving time: about 1.4 s with a cold cache, instant the next time it is opened;
  • the service uses about 250 MB of RAM;
  • agreement with Google Maps: on a sample of real routes the median distance was 1.03× Google's best route, and 8 of 13 routes were within ±5%. The differences usually come from Google picking a different route because of live traffic. A small margin (7%) was enough for quotes.

That is good enough for quoting, planning and estimating travel costs.

Where else Valhalla fits

Transport is only the beginning. Wherever you need travel time or distance, your own engine can replace a paid API:

  • Field service: order technician visits by actual driving time, not straight-line distance. Suggested slots follow the day's route.
  • Deliveries and route planning: travel-time matrices for the optimiser (solver) and delivery windows.
  • Quotes and billing: automatic travel kilometres to the customer.
  • Service coverage: drive-time areas (isochrones), such as "what can we serve within 60 minutes of the branch".
  • On-premise installations: when the system runs at the client's site, often without internet access, an external API is not an option at all.

You can run geocoding yourself too

Routing is only part of the story. Before a system can compute a route, it has to turn an address into coordinates. That is geocoding, and it is usually paid as well.

The same OpenStreetMap data powers Nominatim, an open-source geocoder. In one of our projects we build the map, the routes and the geocoding from a single OSM extract, so the map tiles, routes and addresses all come from the same state of the data and agree with each other. Geocoding runs in the background through a queue: the order is saved immediately and the map point arrives a moment later, so a geocoder outage does not block work.

Two benefits beyond cost:

  • privacy: your customers' addresses never go to an external provider,
  • offline operation: the whole thing can run on a server without internet access.

To be fair: in small villages OpenStreetMap is sometimes incomplete and house numbers are missing. The result is then marked as approximate, and the office can place the point by hand.

When it does not pay off

Running your own engine is not the answer to everything. Stay with a paid API if:

  • you need live traffic: our engine computes times from OSM data, without current congestion;
  • you need truck toll amounts: in one project we still use HERE for exactly that, because it is something free engines cannot replace;
  • your request volume is low: at a few thousand requests a month the provider's free quota usually covers it;
  • nobody can maintain it: map data has to be refreshed (we do it by hand, a few times a year) and the service monitored.

With a high request volume and a need for travel time, distance or addresses, the arithmetic usually comes out the other way.

What follows

If you pay thousands of euros a year for maps, three questions are worth asking:

  1. How many requests do we send each month, and what do we pay for them?
  2. Do we need live traffic and tolls, or are travel time and distance enough?
  3. Can our address and route data leave our infrastructure?

If the answers suggest your own engine could pay off, we are happy to help work it out and, if needed, implement it.

← All articles