Hi community,
When creating an edge between two nodes in GH, we specify the direction of the edge on AccessEnc: forward, backward, or both directions. However, the direction seems not respected when GH’s map matching prepares the input of Viterbi algorithm, especially for virtual nodes as explained in MapMaching#298.
Recently, I found some corner cases where GH’s map matching returns an edge which shouldn’t be accessed in the direction. One of the cases is when a single coordinate is input into GH’s map matching. AFAIK, what happens is as follows:
- The only coordinate is snapped to tower nodes or edges. Let’s consider the closest snap to the query is located on an edge E1 which is a one way link from N1 to N2 on the road network.
- For snaps on edges, virtual nodes are newly introduced to the query graph on top of the original graph
- Each virtual node is used to create two candidates (here the direction on the original graph is not respected)
- Viterbi algorithm computes emission probabilities for the only and first step.
- Viterbi algorithm picks one of the candidate from E1.
- However, the direction of the selected candidate is from N2 to N1, which cannot be accessed on the original graph.
Why is the direction on the original graph not respected when creating candidates? Wouldn’t it decrease the number of candidates to consider in map matching, thus help increasing the performance?
Thanks in advance,
Best,
Dongwon