GraphHopper Routing Engine 0.12 Released

A new release 0.12.0 of the open soure GraphHopper routing engine is available.

The GraphHopper routing engine supported turn restrictions and turn costs only for a subset of its algorithms. After over a year of work on the edge-based routing for the speed mode (Contraction Hierarchy=CH) it is now possible to support turn costs for the speed mode. Our node-based graph model made this tricky and @easbar had to do heavy research on theory and implementation. The alternative would have been to rework our graph model, but the dual graph is not that intuitive and our current solution allows to switch between the faster node-based and the more precise edge-based traversal per request. Read about more details in the documentation. In this process several refactorings and bug fixes were applied, which further improved GraphHopper’s code foundation. For example you can now reuse the node ordering to make CH preparation much faster and the node-based CH preparation itself is now over 15% faster too.

After we made the Isochrone module available as open source in the last version @michaz made it now compatible with public transit. The major difference is that the reachable area is not just one polygon, but a multipolygon that takes into account the various underground or railway stations that you explore further without necessarily being connected to the ‘original’ polygon:

A third bigger change was made by myself. It was always possible to store information per edge like the average speed for car and bike, but 64 bits is not much and several tricks do exist to circumvent this. Now this limit does no longer exist and it it possible to store as many bytes per edge as you have RAM. Furthermore the edge API is now easier to use. E.g. to access information the code ala “edge.get(maxSpeed)” or “edge.get(roadClass)” is sufficient.

Discuss the changes in our forum.

Happy routing!