The German news website heise online reported last week about the release of GraphHopper 0.4:

Quelloffener Routenplaner GraphHopper in Version 0.4 erschienen

Here is the, semi optimal ;), auto-translated text into English.

Read here our official announcement.

Update: there is a new blog post which shows integration of real time traffic info into GraphHopper from a real world example, including a simple UI based on HTML5 canvas.

There are several companies having its own traffic data e.g. those companies having an own fleet or fetching it from an external source. Often on the GraphHopper mailing list people ask how they can integrate this into GraphHopper and until now there was only descriptive information but no code example. This post will change this, where I’ve created a little demo project at github for this task. The demo is easy to use and provides a simple web service where you can POST your own JSON data influencing the routing. If you look at the Readme there are only three steps involved:

• Start the route planner server with the area of your choice: ./td.sh datasource=your-osm-file.pbf
• Visit http://localhost:8989 to try the routing
• Now feed some data and try routing again:

  curl -H "Content-Type: application/json" --data @traffic.json http://localhost:8989/datafeed
  

The simulated traffic jam is marked red. The routing therefore tries to avoid it.

The necessary code is very minimal: just take the double value from JSON and use it as speed for the identified street:

edge.setFlags(carEncoder.setSpeed(edge.getFlags(), value));

A street is a so called ‘edge’ in GraphHopper, read more about internals e.g. in this presentation or in the official documentation. But how to find this GraphHopper edge from the coordinates (list of latitude,longitude)? Currently we just take the very first coordinate of the provided points list in the JSON:

Point point = entry.getPoints().get(0);
QueryResult qr = locationIndex.findClosest(point.lat, point.lon, EdgeFilter.ALL_EDGES);
EdgeIteratorState edge = graph.getEdgeProps(qr.getClosestEdge().getEdge(), Integer.MIN_VALUE);

But in reality this can get more complex and could be improved by using our map matching component. So we just hope here no other edge can be mixed up with a close but completely different edge. Such problems are possible if you get the data from external none-OpenStreetMap data sources or from vehicles on the road without a high precision coordinate information. Other important points on the TODO-list for this demo are that the routing should be locked while updating the graph and that stopping the server should flush the graph to make the newly received data persistent. Nevertheless this shows nicely how easy it is to feed GraphHopper with your own data where the possibilities are endlessly to e.g. block complete roads or prefer roads for routing and more. Let us know about your use case!

Today we are proud to release version 0.4 of our open source road routing engine GraphHopper. Try it out on GraphHopper Maps:

We’ve taken several months for that release, but not without a reason as the GraphHopper Directions API for business was in the works and is also released today! The Directions API is a hosted GraphHopper routing service for world wide usage, including up-to-date software and OpenStreetMap data. It also offers features not found in GraphHopper like address search (aka Geocoding) and the Route Matrix API. Sign up for free and give us feedback!

A big thanks for that 0.4 release goes to all of our contributors! This release also includes features sponsored by Geofabrik and Talent Systems – thanks a lot! Read here to see how to become a sponsor or how to benefit from our GraphHopper knowledge.

Now these are the highlights of GraphHopper 0.4:

• The flexibility mode now supports turn costs and restrictions, with big support from khuebner
• GraphHopper is able to run offline in the browser via TeaVM since 0.3 but now we can also route offline on iOS too! This iOS port was contributed by calin.
• The bidirectional A* avoids heuristical results and is now the fastest algorithm for the flexibility mode
• Via-point support for the web UI, contributed by rbraband
• Roundabout instructions, sponsored by Talent Systems
• More dynamic location lookup which gives a higher success rate and better speed
• A new routing profile motorcycle
• Now GraphHopper contains 26 translations, contributed by several volunteers, special thanks goes to Manfred and his team!
• Improved routing for pedestrians and improved elevation interpolation for the bike2 routing profile
• Important bug fixes for the Android demo, as well as moving to Android studio still preserving Eclipse and NetBeans/maven support
• Improved GPX export
• The national mapping agency for Great Britain Ordnance Survey started work to support also other data sources (not only OpenStreetMap)
• Normal algorithms can work on an already prepared graphs – i.e. speep-up and flexibility mode can be used on the same graph
• Some refactorings to the Java API were necessary, see the full changelog for more details and easier migration
• .. all in all over 40 bugs and issues fixed

Map Matching aka ‘Snap to Road’

There is now also a map matching component based on GraphHopper and released under the Apache License 2.0. This tool can be helpful if you need to track vehicles and import their GPX tracks which is helpful to “snap them to road” like e.g. allryder is using it to optimize urban transport data or attach instructions to GPX files automatically.

Read more about it here or at wikipedia.

Now have fun with GraphHopper and expect more exciting news!