Using Graphhopper as backend

[appelflap]

I wanted to build my own Vroom setup, but the osrm-backend is failing at the moment due to a libc bug in the Docker image and I wasn't able to build it from Dockerfile source due to other bugs in current code.

And I was wondering if it would be possible to use a Graphhopper instance as backend for routing as I already have it running with a europe-latest.osm.pbf. So I would not have to do the whole import part again and run two hungry processes parallel. The basic Graphhopper API provides routing between two points or more points and gives distance, time and weight. And can also optimize a route if you give more than 2 points. Would this be enough though, to substitute osrm-backend? How heavy does vroom lean on the full osrm-backend functionalities.

Maybe it's outside of the scope for the Vroom project and I'll just drop it, but I would be interested in building a wrapper if Graphhopper is compatible with the needed functionality and the Graphhopper routing wrapper has more interest from others.

[jcoupey]

Well the project website states that VROOM is "Extensible to work on top of any routing engine" so this is not out of scope. ;-)

The reason for choosing OSRM as a routing engine in the first place is that it's very fast for matrix computations (and also the C++ context makes it possible to use libosrm for an extra speed-up). But any routing engine would do, as long as it fulfils the current VROOM needs.

1. Prior to optimization: provide a matrix with travel times for any pair of points in a list
2. After optimization (optional -g flag): fire a request for each route to populate the distance indicators in the response and retrieve the detailed geometry as a polyline

I'm not familiar with the Graphhopper API, but I'd say that adding a dedicated wrapper within VROOM would not be too difficult, mostly a matter of re-using and adjusting the existing code. I've never bothered to implement that myself because my own use-cases only imply using OSRM, but I suspect this would be useful for others. So I'd be happy to merge a PR.

@appelflap if you want to handle that, I can provide some more pointers to get you started.

[appelflap]

ok, clear. Thanks for taking the time. The Graphhopper project is written in java and mainly open source. I say mainly, because the API exposing the advanced route optimization over HTTP is intentionally left out. So, calculating route distances and optimizing 1 vehicle driving multiple locations is still working, but more advanced stuff is not. I do not think the basic functions support a matrix with travel times. So it can't substitute OSRM directly. It could still be done, but by making a wrapper that does many calls to make the matrix by itself and return it to Vroom. The calculation speed would be vastly degraded though.

[jcoupey]

You're right, I was not aware that the matrix API is not open-source, but the comparison to the GraphHopper Directions API at the bottom of this page states that clearly.

I wonder what we should do then. As you mention, using many requests to recompose the matrix is ruled out for performance reasons. On the other hand I don't think that adding a wrapper that only benefits to people using the commercial Graphhopper service makes sense.

We should either close this as not actionable, or keep the feature request for the record if there is any chance that the Graphhopper matrix API is open-sourced at some point? (cc @karussell)

[nilsnolde]

Likely we can help you here:
https://github.com/GIScience/openrouteservice/tree/master/openrouteservice/src/main/java/heigit/ors/matrix

openrouteservice also runs in Docker and if you get rid of all the extra options, it runs on similar resources as GraphHopper (after all the same code base).. We use a similar matrix code.

Wait for @sfendrich, who might even have a wrapper at hand.

[jcoupey]

For what it's worth, I'll outline here how to add a routing wrapper based on the existing RoutedWrapper (the one that perform calls to osrm-routed). This would allow VROOM to use internally any other API endpoint that can handle matrix and route queries. Happy to answer questions for anyone wishing to give this a try! ;-)

Define a custom wrapper class

By copying the existing src/routing/routed_wrapper.h and src/routing/routed_wrapper.cpp files and adjusting class names, say to MyWrapper.

Adjust requests to the API syntax

This happens in MyWrapper::build_query that takes a bunch of locations, a service name (table or route for OSRM) and optional extra arguments.

Adjust response parsing

The matrix call

Happens in MyWrapper::get_matrix. The current code already takes care of parsing the response and creating a rapidjson object used to build the Matrix object based on infos["durations"] (durations is OSRM-related and need to be adjusted). We are only interested in retrieving travel times at that point (not distances).

The nb_unfound_from_loc and nb_unfound_to_loc vectors serve for error-handling in case there is an unfound route that shows up in the matrix. OSRM then has a null value so this might need to be adjusted too depending on the API.

The route calls

Those are only fired after optimization when all routes are decided. They allow to retrieve total route distance, elapsed distance per step and detailed geometry as a polyline. The OSRM-related part is here.

Expose the new wrapper

• Add a new routing option in this enum.
• Set this routing option here based on the command-line argument contained in router_arg.
• Add a new case to this switch to handle the new wrapper creation.

[sfendrich]

I opened a new issue for the ORS support here: #203

[jcoupey]

Closing here as not actionable (no support for matrix requests in GraphHopper). Matrix requests are possible using OpenRouteService (based on a fork of GraphHopper), and support for ORS has been added in #204.