The core api produces blazingly fast responses on a CH request as below.
The following route (profile=car + weighting=fastest):
RoutingCHGraph chGraph = hopper.getCHGraphs().get(car_profile); EdgeToEdgeRoutingAlgorithm algo = new CHRoutingAlgorithmFactory(chGraph, queryGraph).createAlgo(pmap); StopWatch watch = new StopWatch().start(); Path path = algo.calcPath(snap_origin.getClosestNode(), snap_destination.getClosestNode()); watch.stop(); System.out.printf("EdgeToEdgeRoutingAlgorithm Path: %.0f kms, computed in %,d ms \n", path.getDistance()/1000, watch.getMillis());
GH returns a 689 kms path in 4 ms. Great as I request thousands of long routes which complete in a matter of just a few seconds.
here’s the route on GH Maps:
As one can see, there is at least one alternative route that is equally interesting.
I am using the following code to get alternatives on a CH graph:
pmap .putObject(INSTRUCTIONS, false) .putObject(Parameters.Routing.ALGORITHM, Parameters.Algorithms.ALT_ROUTE) .putObject(Parameters.Algorithms.AltRoute.MAX_PATHS, 3) .putObject(Parameters.Algorithms.AltRoute.MAX_SHARE, 0.3) .putObject(Parameters.Algorithms.AltRoute.MAX_WEIGHT, 1.5); RoutingCHGraph chGraph = hopper.getCHGraphs().get(car_profile); StopWatch watch1 = new StopWatch().start(); AlternativeRouteCH algoAlternatives = new AlternativeRouteCH(chGraph, pmap); List<Path> paths = algoAlternatives.calcPaths(snap_origin.getClosestNode(), snap_destination.getClosestNode()); watch1.stop();
and there lies the issue.
Now the alternatives takes circa 120 ms to compute. Now the thousands of routes that I request complete in minutes, even when fiddling with the AltRoute.Max_Paths and other parameters the difference is very significant.
Is the 30x order of magnitude of the difference between best path and alternative routes expected behaviour?
Is there anything that can be done to prep the CH graph for “alternative routes”?