### What is a Distance Matrix API?

A Distance Matrix API is a web service that calculates the distances and journey times between a set of origins and destinations. The matrix is normally calculated for a chosen mode of transport and can be one-to-many, or many-to-many.

## Contents

Use cases for a distance matrix are incredibly broad, from fleet optimisation to gravity modelling to B2C search applications.

There are a number of different providers offering similar products to meet these different application areas, often with slightly different features that can be hard to disentangle in order to work out how they stack up against one another.

There are a couple of key areas where differences between different providers are more obvious though:

- what size matrices can you generate, and how quickly?*Usage limits*- how much does it cost to generate matrices of different sizes?*Pricing*

This blog will compare these two criteria for the following providers:

- Google Distance Matrix API
- TravelTime Matrix API
- Mapbox
- TomTom
- Bing
- OpenRouteService
- Nextbillion.ai
- Graphhopper

### Why pick these two criteria for a comparison?

The reason that these two criteria are important may be obvious, but it is worth touching on it briefly.

Without suitable usage limits, a Distance Matrix API may have all the features and functionality that you need to meet your business need in theory, but it just will not do the job. For example, it may take so long to get the data you require, and therefore renders itself unusable.

But even with high enough usage limits, if the pricing model does not match accordingly, then again, the Distance Matrix API will be redundant. It’s all very well being able to generate the data you require in a workable time frame, but if it is prohibitively expensive to do so then you simply will not be able to.

### How to compare the two criteria?

Any benchmarking comparison exercise is obviously dependent on the specific use case of interest, as the pricing and usage limits will work in different ways.

When it comes to usage limits, there is a fair degree of standardisation across the market, with limits normally based on two metrics:

- How many locations can be included in a matrix?
- How many requests can be made to the API in a given time period (usually per minute)?

In other words, *how big *can a single matrix be and *how quickly *can you make multiple matrices?

For pricing, Distance Matrix API providers typically offer some form of free tier, and then charge based on the number of ‘elements’ used.

What is an element?

An element is normally defined as each result in the matrix (i.e the distance and travel time between one origin and one destination. So, for example, a matrix with 1 origin and 1,000 destinations would equate to 1,000 elements (1 x 1,000), while a matrix with 10 origins and 20 destinations would be 200 elements (10 x 20).

Very occasionally a provider will calculate their own unit to price on (e.g “Elements /2”) but the general idea is exactly the same - the more data you need, the more you pay.

In this blog we’re going to consider a couple of typical applications of a Distance Matrix API, but covering two very different use cases and usage profiles:

- A consumer facing search application, that will involve lots of one-to-many matrices
- A route scheduling application that will involve just a few many-to-many matrices

### Scenario 1: Using a distance matrix API on a consumer facing application

In our first hypothetical scenario, we operate a web application that allows users to search for jobs near to where they live. Each time a visitor searches the site, a one-to-many matrix is generated, calculating the distances and journey times between their home location and the locations of all available jobs on the site that match the search criteria (e.g the job title and salary).

In terms of specific values, let’s imagine:

- The site gets 100,000 visitors per month, each conducting a single job search
- There are on average 2,000 live job postings that meet a typical search criteria

This means that each month we need to use a Distance Matrix API to generate 100,000 matrices, each of size 1 x 2,000.

The table above shows how much this would cost for the different Distance Matrix API providers, per month. For consistency, where multiple plans are available, we have taken the highest available plan that is published publicly. As TravelTime pricing is based on concurrency, here we’ve used our Scale plan for comparison, which allows 240 requests per minute - plenty high enough for our job site!

### Scenario 2: Using a distance matrix API for a routing application

In our second hypothetical scenario, our company has a fleet of 50 service engineers, who between them conduct on average 1,250 customer home visits each week. At the start of each week we build a schedule of visits for each engineer based on an efficient routing calculation. To do so, we need to know the driving times from each engineer to each customer home, and from each customer home to each other customer home.

The calculations we make at the start of each week are:

- A matrix of each engineer to each customer (50 x 1,250)
- A matrix of each customer to each customer (1,250 x 1,250)

The table above is a breakdown of how much this would cost for the different Distance Matrix API providers, per month. We’ve also taken the usage limits to calculate how long it would take to get the required amount of data. As TravelTime pricing is based purely on concurrency, here we’ve used our Lite plan for comparison, which allows 60 requests per minute. The time required would be much lower on a higher plan, such as the Rise plan which costs $940 / month and would allow the data to be received in just 11 minutes.

### What do these results mean?

The comparisons of Usage Limits and Pricing can be looked at separately, but if often makes more sense to assess a provider by looking at both together.

For example, if we were looking for a provider to power a location-based search on a web application, then the **very high limits provided by nextbillion.ai (6,000 requests per minute) **look incredibly appealing. When we look at the cost of such high concurrency, however, it quickly becomes apparent that this is **unlikely to be affordable, coming in at over $150,000 per month **just to power 100,000 searches in our hypothetical job site example.

Similarly, if we wanted to use a Distance Matrix API provider to power our route scheduling application example, looking solely at cost makes **TomTom appear to be an attractive option at just $200 per month**. However, when we take into account that for synchronous requests, **there is a limit of 200 locations per request**, and a maximum of 10 requests per minute, it turns out that to run the calculations we need **would take over 12 hours **each week. We’d probably rather pay slightly more to get the data we need much more quickly.

### Why is TravelTime up to X times cheaper than alternatives?

TravelTime is the only provider in the market that does not price on elements (or a metric directly related to elements). Instead, we offer different pricing tiers based solely on the maximum concurrency required. In other words, you simply pick a tier based on how quickly you need to be able to make requests - the price doesn’t change based on how many elements are in each request, or how many requests you make per month.

We call the metric we use to calculate concurrency ‘Credits’. The number of Credits used by a request simply depends on the maximum travel time:

Up to 1 hour : 1 Credit

1 to 2 hours : 2 Credits

2 to 3 hours : 3 Credits

etc.

So based on what sort of requests you need to make, and how quickly, you can pick a fixed price plan to suit.

### Choosing a Distance Matrix API provider to suit your needs

Given the broad range of potential use cases, it’s no real surprise that there are a large number of different providers in the market that offer a Distance Matrix API. When choosing between them, the features and functionality on offer are often broadly similar, but where the biggest differences come in are around Pricing and Usage Limits.

When making your decision, we’d always advise that you map out what sort of usage you are expecting to see, and then pick a provider that can both meet your requirements in terms of usage, but not at a price that is going to blow your budget out of the water.

### Ready to try TravelTime?

TravelTime is built for high volume users focused on performance and data accuracy.

- High usage limits

- Low cost

Try it free:

**Create travel time polygons and matrices with the TravelTime API**

Calculate thousands of travel times with the TravelTime API