I would like to have the path that comes back as the response from a directions request, to be perfectly overlapping with the vector tile layer that we can currently use in the web-bundle of graphhopper.
I already spent several hours trying to remove the douglas-peucker algo and any code that can be linked to simplification but even though I thought I did a complete job, the results are even worse than initially. See below:
I already visited this link and tried the methods suggested in it, however that did not solve the problem, unfortunately.
The first thing I tried was setting way_point_max_distance to zero but that did nothing. Then I started going through the code to remove all logic that has anything to do with simplification.
It was what you suggested, actually:
Do you have any further ideas?
I am aware after reading a lot of entries from this forum, that the edges first get simplified upon import, which is fine. I just need the routing and map matching response paths to align with the edge network stored in graphhopper. In my use case there is absolutely no need for simplification.
This should be unrelated to your problem. The simplification is not entirely disabled, this is true and therefor points perfectly on a line won’t be removed but for curves, like in your case, it won’t remove any points if you specify 0.
The first thing I tried was setting way_point_max_distance to zero but that did nothing.
Did you specify the configs for the import (in the config) and request? (note that they are slightly differently named)
I also noticed this many times. I’m not sure if this is related to path simplification at all, for example here we see that even the junction node is shifted:
If you watch this screen video you’ll see that the difference is at least somewhat systematic.
In other words, the deviation of the generated routes’ vertices is always within the 180°-270° heading interval from the vertices of the MVT edges. Therefore I suspect there has to be a way to either correct the MVT or correct the generated route. The problem is that at the moment there is nothing that can be used as the universal source of truth when you try to compare the route to the route network.
Upon import it is already known that the edges do get simplified to a certain degree, but there is just no way to see the edges of the current graph.
A suggestion perhaps: Is there a relatively easy way to implement the export of a simple graph, like Berlin or Andorra to a shapefile?
The source of truth should be the coordinates of the vertices stored on the server side. I suspect the mismatch is only due to the way these coordinates are rendered on the map. For the route they are rendered by the JavaScript mapping library (open layers), while for /mvt the map tiles are created on the server side. May I ask why you think it is important that there is no such mismatch? I mean other than that it looks somewhat broken like this, of course?
Sure, I can explain why: If you want to detect the name of streets that cross the generated route track along the track’s entire length for example, you’d approach this problem using two possible ways. Both involve PostGIS on my end ATM:
(A) Check using a table containing preprocessed (based on the OSM route network) junction points, which of these junction points spatially intersect the route track. In an ideal world, this should be the way to go as it allows virtually zero errors and offers no surprises.
(B) Using a preprocessed (based on the OSM route network) table that contains circular buffers of N meters around each junction. Use this table in a PostGIS query that accepts the generated route track as the input geometry and determines which circular buffers spatially intersect with it. The reason for using the circular buffers here is to make up for the imprecision of the generated route when we compare it against the junction nodes (points)
The problem with approach (B) is that if the selected radius is bigger, say 3m<, then multiple circular buffer zones around the junction points start to overlap, which would give the user false values, for example a name of the street that does not even cross the generated route track.
I totally agree with you on this one! That was exactly why I was asking for some guidance on how to implement an export function that exports the graph that GH created into a shapefile or even better, a PostGIS table.
I am aware that it is a considerable amount of work and am not asking you to do it for me. But I’d be glad to receive pointers from you on how I could get started building such a feature.
