I am using the routing engine to give my users a route based on there waypoints they put in, easy enough. All works well but sometimes (usually when users use more than 3 waypoints) all the snapped waypoints is not present in the points. This is a big problem for me as i am simplifying the points in between the waypoints and when one is not present it messes things up. This feels like a bug in the return from the routing engine because mostly the snapped_waypoints are present in the points array but sometimes not all of them are, usually the seconds to last.
When i use these waypoints it always happens that the second to last waypoint is not present in points
Input points:
[ [ 11.97578, 57.69274 ],
[ 12.31084, 58.31784 ],
[ 12.3855, 58.77117 ],
[ 12.93736, 59.13954 ],
[ 14.3816, 59.20472 ],
[ 13.26714, 58.10976 ] ]
return
snapped_waypoints:
[ [ 57.69273, 11.97578 ],
[ 58.31784, 12.31083 ],
[ 58.77116, 12.3855 ],
[ 59.13952, 12.93738 ],
[ 59.20472, 14.38159 ],
[ 58.10975, 13.26713 ] ]
points:
to long to paste here but when i try to find each snapped_waypoint in points i get
Found: 57.69273,11.97578
Not found: 58.31784,12.31083
Found: 58.77116,12.3855
Not found: 59.13952,12.93738
Not found: 59.20472,14.38159
Found: 58.10975,13.26713
I have no experience with java so i am having a hard time finding problems in the routing engine myself.
it looks like your second to last point is located in the middle of an edge, i.e. it lies on a straight line between the previous and the next bend of the road:
In this case GraphHopper will remove it as it isn’t required to resemble the road geometry (the path is simplified).
You can disable this path simplification using way_point_max_distance=0. I checked that in this case your point will be included, but this comes at the cost of a larger response size (because no points will be removed).
Anyway, I think I agree that via points should not be removed for the path simplification. @karussell is there any reason we do this?
That as well, yes. For example your second point: Not found: 58.31784,12.31083
is already included, and the actual returned value in snapped_waypoints is: 58.317837, 12.310843
Isn’t the problem that the snapped_waypoint can and will be different than the input points?
Snapping means to find a location on the road which is often different compared to the input point. To find the input points you could use the instructions to split the route in “legs”: Routing API: Using Path Details - GraphHopper Directions API
Anyway, I think I agree that via points should not be removed for the path simplification. @karussell is there any reason we do this?
Yes, but it sounds like @Ben_Dav was trying to find the snapped waypoints in the returned points list.
But how could this made reliable when the snapping points can be vastly different?
I think the preferred method should be via the instructions as linked above.
as i am simplifying the points in between the waypoints
@Ben_Dav You could use the undocumented query parameter way_point_max_distance for that (default is 1 and you would need to increase this I think) and avoid finding the input points.
I am trying to find the snapped_waypoints in the points list not my input waypoints
I need to know where the snapped_waypoints are because i run the points (simplifyied to a set limit based on route distance) through mapbox api to handle navigation. Our main issue is that we need to know the exact index of the input waypoints in the returned points list.
Is this the best way if i want to know the index for each snapped_waypoint in the points array
i don’t quite understand the rounding you mention, I am using an unmodified version of Graphhopper routing engine v4. So the example above is what i put in and get back from the route endpoint without me doing anything.
does contain the second to last snapped waypoint. The index you are looking for is 2834. Do you get another response running your own GraphHopper instance?
