Hi,
I have implemented a custom endpoint/resource which allows us to modify edges dynamically from our product so that users of our app can close roads, change speeds, max width etc. and have that instantly reflect when performing route requests.
This is similar in functionality to what was mentioned here - Integrate traffic data into your route planner - GraphHopper Directions API but gets updates pushed to it via the new resource rather than pulling from a specific source but I cannot see any mention of that functionality after that blog post, so was wondering if this would be a worthy addition to the open-source project so that multiple users could gain this functionality?
I would like to know the likelihood of this being considered before making the effort of implementation.
Yeah, such an endpoint sounds interesting. But if we accept this is hard to tell before the impact is seen in the code …
We had a similar feature but the problem was that this required locking due to the graph storage and the speed ups would have to be updated etc … so some big limitations and overhead. This and the low interests lead to the fact that we removed this endpoint before the 1.0 release.
What is the reason you don’t do the data changes directly to OSM and do a reimport?
Thanks for the quick reply - the reason for not doing a reimport is that the requirements are that when an adjustment is made by the user, their changes should be “instantly” persisted to the routing calculations. The time required for a reimport would be unacceptable for our customer’s usecase.
I suppose that could be a potential solution - we had originally considered dynamic custom models, but expected there to be so many modifications that it would make every request bloated. I hadn’t considered a combination of dynamic models and reimport, but with multiple operators making changes throughout the country I suspect this may end up in a loop of constant reimports and add excessive complexity to our synchronisation process. I will have a look into that though.
Also - another feature I use during this process is returning an edge from a single gps point (using LocationIndex.findClosest() and Snap.getClosestEdge()) which I would need so that the operators know which road section(s) and the current properties (speed, width etc.) of that road section they are modifying via a single click of their map. Is there a good way to do this with the current api that I am missing? The map matching api returns a similar result, but doesn’t quire fit the usecase.
In the web UI you can enable the Show Routing Graph checkbox in the layer menu. This will show a popup containing all edge properties when you hover an edge. It is implemented via the /mvt endpoint (MVTResource.java) which fetches these properties for a all edges in a given bounding box so you could also use this endpoint directly. There is also the /nearest endpoint which returns the coordinates of the closest edge that you could modify to return the edge properties as well.
Depending on your usecase you should also take a look at ExternalBooleanEncodedValue which demonstrates how to store edge properties outside of the routing graph. This way you could still treat the graph as read-only data structure after the initial import and store everything that is subject to change in another way.
…