Use the new “hybrid mode” for map matching

Hi there!

By reading the 0.9 release notes I saw there is a new “hybrid mode” which speeds up routing calculation.
Additionally the git thread - ALT algorithm for a more dynamic speed up- references the following thread : Allow map matching to use CH too.

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.

Sincerely,
Arthur Vaïsse-Lesteven.

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 ?

Sincerely,
Arthur.

It might be the fix of https://github.com/graphhopper/map-matching/issues/70 that causes the slow down. But 10x sounds a bit too much.

Don’t saw any log related to the new hybrid / landmark algorithm.

You’ll probably have to debug if the new algo is actually called

It might be the fix of https://github.com/graphhopper/map-matching/issues/701 that causes the slow down. But 10x >sounds a bit too much.

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

Ok I will take a deeper look.

Anyway, thank for your quick reply!

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?

Have opened an issue

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).