And the ALT algorithm thread said to enable it we should use the following properties prepare.lm.weightings=fastest #in the config.properties ch.disable=true #if CH is enabled
My understanding of the map matching tool is that it is ( or was) incompatible with contraction hierarchies (CH). By reading the news I feel like the new algorithm required CH to be disabled and so the map matching tool should be able to use it.
If that so, how could I use it ? I currently use the following code in my application to configure my graph hooper instance :
AlgorithmOptions.start() .maxVisitedNodes(500) .algorithm(Parameters.Algorithms.ASTAR) .traversalMode(hopper.getTraversalMode()) .build();
I do not see any fastest or hydrid algorithm.
Yes, it would be really interesting if this speeds up map matching but haven’t yet the time to test this.
ch.disable=true #if CH is enabled
This is done for the request, so something like algorithmOptions.getHints().put(“ch.disable”, true).put(“lm.disable”, false) but not sure if the hybrid mode is then triggered or if the settings are more static.
Okay we tried what you suggested. Don’t saw any log related to the new hybrid / landmark algorithm.
However the mapmatch took 10x more time to proceed in version 0.9.0. In fact it took so many time we had to downgrade the graphhopper version to get back the 0.8.2 version.
I looked for the changelog of the version 0.9.0 but link seems to be dead ( 404 ). Do you have any idea of what change could cause such a slow down ?
Don’t know if this modification explain the slow down by itselt, but I’m pretty confident in the slow down factor I gave.
We use the mapmatching tool to process roughtly 12 000 000 GPS track.
We were able to mapmatch them all at a rate of 60/seconds using graphhopper version 0.8.2
Using the version 0.9.0 without modifying anything else the processing rate reduce to 6/second.
You’ll probably have to debug if the new algo is actually called
This is ugly. Can you somehow identify the differences e.g. via a profiler? And do you have ‘normal’ car tracks or e.g. lots of points per meter or extremely rare points?
I’m pretty confident in the slow down factor I gave.
I suggest running the (undocumented) Measurement suite, and putting the results in the issue above. CH did/does work, but I seem to recall it can actually slow things down (searches more candidates than without, for short separations).
We use the mapmatching tool to process roughtly 12 000 000 GPS track.
If you’re interested, it is possible to do trillions, but it requires a fair bit of customization. Some gains are relatively straightforward optimizations of e.g. the Viterbi algorithm, while others are a bit more fun - basically solution 2 of here. If the above interests you, I could help advise - but not develop (at least for the next few months). Anyway, upvote the prior issue or (possibly) create a new one for ‘big data map matching’ (though it might pay to discuss it first here).