I’ve extended GraphHopper to incorporate some custom weightings by implementing several custom Weighting classes. These are working quite well, and it’s interesting to see the contrast in routes produced by the standard “fastest” weighting compared to my custom weighting.
I’m sometimes running into a problem, though, when using another custom weighting class that is based on the “fastest” weighting but adds my own custom weighting into the equation. This custom weighting class seems to usually negotiate quite well between the “fastest” weighting and my new variable, except for very long routes.
As an example, the route from San Francisco to Los Angeles is handily returned when using either “fastest” or my other simple custom weighting. However, when using the other custom weighting class, based on both “fastest” and “shortest” under the covers, I end up getting the error “Connections between locations not found”.
Reading discussions about this error, I ended up with the following combination of network_size configuration parms:
This hasn’t done anything to address the issue. What is the best approach for troubleshooting this issue, and are there any other configuration parameters to try changing?
It is hard to tell what the problem is without seeing the modifications you have done. The first thing I would do is shifting the route markers to make the route shorter and shorter until a connection was found. In most cases it is just a single road that is blocked and disconnects two points. Or do you get connection not found errors no matter where your start/end locations are?
I get good routes for all of my shorter trips, but when taking a long trip (e.g. from San Francisco to Los Angeles), I get the connection not found errors. So, I can certainly try to find the point where it stops working.
From that point, can you suggest what’s the best way to then determine what road segment and what parts of the OSM data are causing the problem?
Actually, I don’t need an answer to that. Once I’ve narrowed down the lat/lon ranges, I can simply add logging in my custom Weighting classes, reporting each component weight result. I think there are some cases in which the FastestWeighting class reports a weight of Double.POSITIVE_INFINITY, and that would certainly cause a blockage.
Yes exactly after you narrowed down the range you can just debug like you proposed. By the way if its really like you get connection not found for all longer distance routes it could be helpful to visualize the shortest path tree. There is a demo UI app under localhost:8989/maps/isochrone/ that lets you click the map and show the isochrone or shortest path tree. If longer distance routes are not connected you should see the shortest path tree stop at some boundary for example. Just speculating though.
