Comparing Isochrone APIs: an insight into different providers

In the past I was working on different plugins to connect with multiple APIs and use their isochrone endpoints in QGIS. Let me summarize some of my findings and share my opinion on HERE, Azure Maps, Bing Maps, ORS, Esri and Iso4App.

Isochrones: the “test case”

The test case itself was a very simple one. I don’t wanted to judge the base data so I chose a region were I expect to have very good data coverage (and of course I know the city): Berlin, Germany. From a parameter perspective I haven’t changed so much and sticked to the default params from the providers:

1. 20 min isochrone
2. fastest route
3. go by car
4. no traffic

The tests were created in QGIS with the plugins HQGIS, ISO4App, ORS Tools. Unfortunately I haven’t developed the isochrone processing for the A-Maps plugin yet, so I used a S1-tier key (more about this later on) and created the polygon from the API results manually. The same applies to the Bing Maps and Esri API.

Isochrones Compared

TLDR: The isochrones for each provider in this gallery: As you can see, there are huge differences in number of vertices and extent. The AMI (Azure Maps isochrone) has the largest extent. Yet this is somehow comparable to the ones from HERE and ORS. Only the iso4app is very conservative in terms of travel speeds and therefore reachable areas by car. It looks more like the accessible area for a bicycle mode:

iso4app

iso4app is somehow new to me. Their routing/isochrones are based on OSM. The dialogue offers some customization and it looks comparable to the ones from HQGIS: The plugin creates a point and polygon layer in your project and the polygon. The resulting isochrone is way to small for the given set of parameters. As seen above, it does not really make a difference whether you’re on a bike or in a car. This may be the result of very low speed conversion values on the edges of the graph. From a cost perspective, iso4app offers you 60 credits per day and 10 requests per day for free. They have some pay as you go plans which, in my opinion, are quite expensive: But we need to keep in mind that the company behind iso4app is a smaller one.

Azure Maps

First of all: don’t shoot the messenger. Azure Maps’ routing engine relies (in terms of isochrones) on the TomTom API which is somehow offered through Azure Maps. They don’t even changed the response header. So the AMI service is mainly the TomTom “reachable range” API endpoint. The parameters are diverse and you can customize it heavily. And, this is new to me, TomTom offers a very detailed consumption approach for electric cars as well. Personally I think the API is a bit to detailed in the first level and I would add some of the parameters as a nested JSON as properties of the consumption type to make it easier to read and setup:

The result of the API call is a proper JSON with a maximum of 50 vertices. This leads to a very coarse isochrone and I haven’t found any way to increase precision or details. The isochrone endpoint desires a S1 tier key. This will give you no free credits at all and you need to pay approx. 5€ per 1000 transactions / API calls. Quite a heavy price tag for such a result:

The result not only has the boundaries (where every coordinate is not a lat long array but every point has the keys “latitude” and “longitude” with the relevant values) but also gives you a center coordinate which is more or less your starting point and should not be taken as a center in a “centroid” perspective. The URL used for the call was as follows: https://atlas.microsoft.com/route/range/json?&api-version=1.0&query=52.520008,13.404954&timeBudgetInSec=1200&subscription-key=YOUR_FANCY_KEY_HERE

Bing Maps

Another Microsoft Product, Bing Maps, is performing a bit better compared to the Azure Maps result in terms of “precision”. That might be the result of using HERE data as the basis but yet I think it could be better! The dev center is a bit scattered and it is hard for me to get a right idea about what is for free and what is included in an account. Despite this, the isochrone endpoint offers you the” standard parameters” for routing like traffic yes/no, travel mode, isochrone by “distances in meter or minute” and so on. The response json has the coordinates only. But why the heck are the coordinates flipped and have a latitude (y) in the first place?!

Looking at the shape, we can conclude, that the API also uses a very rough estimator for isochrones and oversimplifies the result:

The data was gathered with this URL call and some ETL magic. No plugin is involved yet: https://dev.virtualearth.net/REST/v1/Routes/Isochrones?waypoint=52.520008,13.404954&maxTime=20&TimeUnit=minute&optimize=time&travelMode=driving&key=PLACE_YOUR_BING_KEY_HERE

HERE

People- following this blog- know, that I am quite in love with the HERE dev-program and the capabilities that come with the HERE Freemium account. For the API call I used the HQGIS plugin, I developed, and altered the parameters according our above scenario. We can see, that the results are much better looking at the vertex density. Yet they are bit more buffered along the edges compared to Esri’s approach of sticking a bit more to the network:

The parameters are more of the normal kind like “start at”, “traffic yes/no”, “time of departure” and so on. Additionally the modes are quite diverse: car, truck, pedestrian, bicycle, public transport,… (some of them are not yet supported for “isolines”, as HERE calls the isochrones, which also more precise). In line with the 250.000 credits per month this is quite a good offer. The response of the API has not only the shape but also the center coordinate (like Bing Maps above) and the distance indicator. Unfortunately the coordinates are returned as strings, which makes it necessary to parse it into a decimal number format. This is not a good design and should be updated in the future.

Esri

There are some quite good details in the isochrone:

The underlying network dataset is also from HERE but Esri really pushes this to the limit. The number of parameters is huge as this API is not only for creating isochrones. They call these “service areas” for facilities. This said, the use case is more or less the same. As there is no processing/plugin available yet, I’ve used the following URL: http://route.arcgis.com/arcgis/rest/services/World/ServiceAreas/NAServer/ServiceArea_World/solveServiceArea?facilities=13.404954,52.520008&defaultBreaks=20&outSR=4326&f=pjson&token=YOUR_FANCY_TOKEN The response from the API is bit more detailed and gives you not only the shape and center but also some titles and area attributes:

With the free developer account you can query about 100 service areas a month (50 credits are included). If we use the retail price for 1000 credits at 180€ (German distributor price). In the US, the price is approx 50% lower. In the end: quality does not come for free, does it.

ORS

Keeping the last statement in mind we will now look at OpenRouteService, queried using the ORS Tools plugin from GIS OPS, which are based in Germany and have their roots in Heidelberg with their OpenRouteService page. The plugin is mostly using the processing toolbox which is a great approach in my point of view:

The algorithm offers plenty of travel modes but no traffic integration yet. The resulting layer in QGIS already has- as the only one of those APIs- a population indicator embedded which shows the number of persons in the isochrone:

ORS offers 500 isochrones per day, which will sum up to 15’000 per month. Looking at the detail of the response: Nice!

Summary

Here a short summary of the most “facts”. If something is wrong or missing, please drop a comment!