Don’t hesitate to contact us:
Today we are happy to announce the new release of our open source routing engine. It is again packed with new features, bug fixes and nice improvements. This time we put our main focus on the custom routing feature that we already included in version 1.0 about a year ago. With the GraphHopper engine you can calculate ideal routes for different motorized vehicles, bikes and walking modes for every city and country in the world, because it builds on the comprehensive map data provided by OpenStreetMaps.
With custom routing you can take this one step further and adjust the route calculations to your personal preferences, properties of your vehicle or peculiarities of the map data in your region. For example it is now easy to avoid motorways, ferries, toll roads or entire areas. You can also use certain OpenStreetMap properties like surface, max_speed, hazmat (hazardous materials), max_weight etc. to specify on which roads you like to drive or to adjust your typical driving speed.
And the best part: all this is possible without any programming knowledge!
Now let’s take a look at the most important changes in our new release 3.0:
As you might already know the custom routing feature is based on a set of rules that you can use to specify the speed and priority depending on the road attributes. These rules are written in the simple JSON syntax and for the new release we made the syntax a lot more powerful and readable. For example you can now easily combine road attributes to set rules like “lower the speed on tertiary gravel roads” or limit a rule to a certain area. With these changes we are now confident that the syntax covers most use-cases and we are already planning to include more possibilities like setting up turn costs or including elevation data.
We also made it a lot more comfortable for you to enter custom routing rules. Our GraphHopper Maps app now includes an interactive text editor that guides you when writing a custom model. It not only notifies you about syntax errors, but also shows auto-complete suggestions about what kind of rules you can set up and what kind of road attributes are contained in the underlying map data used by your GraphHopper instance.
The custom model rules you can see in the above screenshot are now simply written as a separate
custom_model field in the routing request that you can send to the
POST /route endpoint of the GraphHopper server. We removed the
/route-custom endpoint as it is no longer needed and
/route now fully supports custom routing. For more details please take a look at the documentation and if you’d like to use custom routing for our commercial GraphHopper Directions API please contact us.
There is one more thing we’d like to point out: Custom routing models can not only be used on a per-request basis, but you can copy and paste your favorite model to your server-side configuration and use it with GraphHopper’s speed-up techniques like Contraction Hierarchies and Landmarks as well to achieve blazing fast response times.
We improved the visualization of path details in GraphHopper Maps and this is especially useful in combination with custom routing. With path details you can show the different road attributes along your route.
GraphHopper should not only be highly customizable, but one of our main goals is that it also works really fast. In this release we made big improvements in this direction again:
We moved our previously separate repository “graphhopper/map-matching” for the “snap to road” feature into “graphhopper/graphhopper” to make usage and development easier. See the new documentation.
We added a new demo app to show the results of our
/spt endpoints. With this you can now see the shortest path tree or isochrones (line of points with equal distances from an origin point) in your browser. It does not support custom routing requests, yet, but you can already use it with custom models defined in your server configuration.
We merged over 70 pull requests. Some of the most noteworthy changes are:
config.ymlor put into separate JSON or YAML files in an arbitrary directory (#2232)
toleranceparameter for the
sac_scaleand path details like
isochronemodules into core
Thanks to all contributors:
easbar, michaz, joe-akeem, GProbo, otbutz, karussell, boldtrn, HarelM, hoofstephan, braito4
Last but not least we made it even easier to contribute to our open source projects. Just add yourself to the contributor list in your first contribution and you are done. No need to sign a CLA, even though we never used the CLA to change ownership or similar. See this issue for more details. Of course you still have to agree that your contribution stands under the Apache License 2.0.