I am looking into an incorrect map matching issue where points are routed onto a motorway link rather than taking the fastest path along the motorway (see attached images).

I can reproduce the result with a very small number of points. One difference I found is that when an additonal point (point 5) is added to the data set, it seems to change the candidate snaps for the first GPX entry. This is odd, since I though “lookupGPXEntries” in MppMatching only performs a spatial lookup of individual points against the graph.

We are seeing many examples of incorrect routing onto a motorway_link. It is commonly seen where the main “motorway” class is tagged with a maxspeed restriction where the motorway link is not.
However, even after reducing the default speed of “motorway_link” in my CustomCarFlagEncoder to a 10 (for testing purposes), I don’t see a change in map matching behavior.
Above, with 2 data sets (one with 4 points and one with 5), the one with 4 points selects the correct route where the 5-point dataset doesn’t. I’ve verified that snap candidates are identical between the two. The issue occurs somewhere in the assignment of weights as part of the routing call performed by DijkstraBidirectionRef.

I’ve tried other approaches - using PriorityWeighting. I can only get the correct route by adding “motorway_link” to an avoidSet at worst priority, but this is non-ideal and will cause issues for other datasets.

We have many examples of this behavior. Here are some of them where the wrong road is chosen after the road is split:

This is really strange. Usually those problems occur if the weight on the motorway_link is lower. And so it should be fixed if you set the speed of the motorway_link to a lower speed (i.e. higher weight) compared to the maxspeed of the motorway.

Above, with 2 data sets (one with 4 points and one with 5), the one with 4 points selects the correct route where the 5-point dataset doesn’t. I’ve verified that snap candidates are identical between the two.

Are you able to reproduce the issue with the latest master? Then you could build a failing test and send us a link to your fork so we could investigate this on our side.

Yes, the roads which are impacted typically have a maxspeed restriction that is lower than the motorway_link speed, but to get around this, in our custom implementation of CarFlagEncoder, we are setting the default motorway_link speed purposely to a very low value:
// autobahn
defaultSpeedMap.put(“motorway”, 100);
defaultSpeedMap.put(“motorway_link”, 30);
// using priority weighting
preferSet.add(“motorway”);
// avoided road classifications wiith priority level set to “AVOID_IF_POSSIBLE”
avoidSet.add(“motorway_link”);

But as you can see I can reproduce the same problem that you mentioned with our hosted Directions API (snapping to the motorway_link). Was able to reproduce this for the open source routing engine even when setting the speed of motorway_link to 5km/h. Have created an issue to track the progress of this bug: https://github.com/graphhopper/map-matching/issues/147