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!

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 openstreetmap.org 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.

To make the JVM wait for the agent to connect before starting the application just specify suspend=y.

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 GraphHopper.java. 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 you 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!