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!

We are happy to announce our new API docs. We specified our APIs in the OpenAPI specification language and moved the entire content of our old documentation to a single OpenApi 3.0 document.

This has many advantages: There is only a single source for the documentation of new features, and for generating client code to make it easier to use our APIs in your favorite programming language. Furthermore, it is much more developer friendly, since it is precisely specified what our web services expect as input and what developers can expect as output. Even though our docs become more technical this way, we think that it is still easy to read, navigate and understand, and it still has a beautiful look. Additionally, the document is under version control, so our public github repository allows developers to open issues and pull requests to further improve the documentation.

To generate our API docs, we use ReDoc and create-openapi-rep to manage the specification lifecycle. This helps us to practice continuous integration with Travis CI, i.e. each commit to the specification is validated against the OpenApi 3.0 specification and deployed to our documentation pages.

If you have questions, comments or if you think our docs are much harder to understand now, please feel free to contact us.

Happy Routing! Your GraphHopper Team.