Hi GraphHopper community,
I am currently working on map-matching for pedestrian/hiking traces. I’ve noticed a specific behavior where U-turns in the matched output are always forced at the next real intersection, even when the GPS observations clearly indicate that the user turned back in the middle of a street/path.
After analyzing the source code, I believe I’ve identified the two main reasons for this:
-
Traversal mode: In
MapMatching.java, therouterFromGraphHoppermethod is hardcoded to useTraversalMode.EDGE_BASED. While this is ideal for vehicles to handle turn restrictions, it seems to prevent the router from performing a 180° turn “on the spot” at a virtual node. -
Edge resolution: The
prepareEdgeMatchesmethod usesresolveToRealEdge, which maps virtual nodes back to the original edge keys. This ensures results go from intersection to intersection, but it seems to “stretch” the U-turn to the nearest tower nodes.
For a pedestrian, pivoting 180° mid-segment is a natural and frequent behavior. I am considering modifying the code to allow TraversalMode.NODE_BASED when a pedestrian profile is used.
My questions are:
-
Has anyone already experimented with switching the Map-Matching API to
NODE_BASEDtraversal? -
Would this change be enough to allow the Viterbi algorithm to transition between two virtual edges in opposite directions at the same snap point without routing to the next intersection?
-
Are there any known side effects on the HMM probabilities or the
queryGraphlogic when forcingNODE_BASEDin this context?
I would appreciate any insights or feedback on this approach!
Best regards, Arnaud