Graphhopper Directions API News October

A long silence for a young company can mean many different things. In our case it only means that we further concentrate on making our products better! We are very happy to improve the GraphHopper Directions API every week and keep you up to date with this newsletter.

We improved the Route Optimization API in various ways:

We released version 0.8 of our open source routing engine coming now with 39 translations, which are directly available in the Routing API.

A new Map Matching API was released which does an automated ‘snap to road’ useful to improve recorded GPS traces:

Map Matching API Demo
A lot more is happening in the GraphHopper space: we had our first, very own GraphHopper meeting, spoke at IAA, FOSSGIS, … and reached a new star record for our open source projects (sum is over 1400!).
You can now follow us not only on Twitter but also on LinkedIn and Facebook. Or visit us at WhereCamp Berlin or at Startup-DemoNight in Munich in real life.
Over the last months we were very happy to welcome dozens of new customers, bigger and smaller – hello again 🙂 !

If you have questions or problems, do not hesitate to contact us!

Happy Routing!
Your GraphHopper Team

GraphHopper Routing Engine 0.8 Released

We are proud to release version 0.8 of our open source GraphHopper routing engine! Here is the polished snap-to-road feature in two screenshots:


A big thanks goes to all of our contributors and translators!

To become a contributor see our contributing guidelines and e.g. the good first issues. Read here to see how to become a sponsor and how to benefit from our expertise or donate us.

Here are the highlights for GraphHopper 0.8:

  • the new map matching algorithm based on hidden markov chains is finally integrated and gives us a big quality improvement, thanks to @michaz (GraphHopper) and @stefanholder (BMW Car IT). This feature was already deployed 2 months ago in our GraphHopper Directions API. Some improvements were done by @kodonnell.
  • the osm import module is split from the core #450 making Android and iOS integration cleaner
  • there is a new overlay module #781 allowing you to specify GeoJSON at import time to change properties like access and speed of the routing graph
  • new ‘more standard’ code formatting for all repositories #770
  • many UI fixes like upgrading to leaflet 1.0, thanks to @fbonzon (Bikewithme)
  • updated the iOS port, thanks to Calin @clns
  • travis build enhancements like running against jdk9 and deploying snapshots #806, thanks to @mprins
  • a new ‘on-demand’ weighting with a new data encoder #730
  • elevation interpolation in tunnels&bridges #713, thanks to @highsource (DB Systel)
  • fixing time calculation for turn costs #393
  • a new short_fastest weighting #747
  • Several updates to Android build/sample from @devemux86 (talent)
  • several bug fixes (incl. three major)

The changelog is here – please read about the necessary changes to your and/or your Java code. Dowload the new version here. As the documentation has slightly improved we’d like your input here as well.

In the next release we expect bigger changes to come like one top secret 😉 and this exciting work from @devemux86 which continues the work from VTM (OpenScienceMap) and has OpenGL support, allows map rotation, iOS support and more, while keeping compatibility with the Mapsforge file format.

And if you like OpenStreetMap as we do, consider supporting them via money.

Happy routing!

Releasing the Map Matching API

Today we are proud to release our Map Matching API as part of our Directions API. It is a web service based on one of our open source components. You can use it to snap measured GPS points to a digital road network to e.g. clean data or attach certain data to it like turn instructions for biking trials. Read more about map matching at Wikipedia. Our Map Matching API is powered by the Apache licensed hmm-lib from BMW Car IT. ‘hmm’ stands for hidden markov model and indicates the underlying algorithm.

In the following screenshot and in these live examples you can see the Map Matching API in action. The black line represents the original GPS track e.g. received from a smartphone’s GPS. The green line represents the matched result, i.e. the part of the digital network, the black line is matched to:



The Map Matching API works through tunnels, bridges, complex junctions etc. and can utilize different available vehicle profiles. Even more off-the-road examples will snap correctly – depending on the chosen GPS accuracy:


We are confident that it is another helpful routing tool that can be used in production for your web or mobile application. If you find any example where our Map Matching does not work as expected, please let us know in the forum.

Use this link to sign up and try the API for 2 weeks and let us know about your GPS tracks and questions!

The daily bug hunt

Yesterday we got a support request that a certain route request fails and just says ‘route not found’. We wanted to quickly reply that the open source routing engine has an option where you can reduce to a sufficient minimum, but as it turned out he meant the hosted GraphHopper Routing API where we already use a properly configured engine. So something was wrong with it. And in the geographical area we detected nothing strange with the OpenStreetMap data, (although for Google Maps we found one ;)) and so it had to be something in the routing engine.

Grabbing the area via the export button at was easily done, but we could not reproduce this on my local machine. And so we would need to somehow use the remote data, which is a bit too big to fit on my local computer (~50GB).

How do you remotely debug a Java application in a safe way?


Let me explain this for NetBeans but it should work similar for any other Java IDE. Add the following options to your remote Java application:

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8888 ...

You can find out more about these settings via

java -agentlib:jdwp=help

As a side note: there is also an old settings “-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8888,suspend=n” but for that we got an error: “OutOfMemoryError: Java heap space” which did not go away even when trippling the -Xmx setting (maximum RAM for the JVM). After switching to a different off-heap graph storage method (MMAP_STORE_SYNC) we got it working with the old method.

Now, how can you open the port 8888 without making it public to anyone? Instead just 8888 use localhost:8888, then the socket is not publicly accessible and so you can safely access it through a SSH tunnel:

ssh -L 8888:localhost:8888 user@server

Then click ‘Debug’ in the Netbeans menu, then ‘Attach Debugger’ and press ‘okay’. Keep localhost and 8888 or if you do not have a SSH tunnel use the remote server IP. It should then open a new output window telling you that you are connected. In our case we still had a problem:

Not able to submit breakpoint LineBreakpoint Reason: Breakpoint's source file does not belong into the preferred source root '.../.m2/repository/com/graphhopper/graphhopper/0.7.0/graphhopper-0.7.0-sources.jar'

This is easy to fix. Go to Window->Debugging->Sources and deselect the entry for graphhopper 0.7.0 as the open project with 0.8-SNAPSHOT itself is sufficient in my case.

Finally er were able to remotely debug into the JVM

Nice! But we were still not able to figure out what went wrong ;(

The reason was that this bug was not related to runtime (i.e. finding the route) but it was related to how we post-process the OpenStreetMap network to make it less error-prone. Read more about the details here and if you liked this maybe you would like to contribute 🙂 ? Have a look into our quickstart and sign-up to our forum.


We hope you enjoyed reading this bug hunt and you can apply the findings to your own debug sessions!