Closed tlian-lainie closed 2 years ago
Thanks for raising this problem. Sometimes I also encounter an issue like this. Perhaps you can sparsify the trajectory to see if it works. I am still working on improving the algorithm so in the future there would be other configurations to correct the matching.
Thanks for raising this problem. Sometimes I also encounter an issue like this. Perhaps you can sparsify the trajectory to see if it works. I am still working on improving the algorithm so in the future there would be other configurations to correct the matching.
Thanks a lot, Can. A prompt response again! Yes, I found the GPS points around this type of error are somewhat crowded. Perhaps I will delete the crowded points with extremely low speed. Thanks.
Describe the bug Hi, Can. Hope you are doing well.
I have been exploring fmm for a while. Encountered a problem today. Could you please help to identify the reason for a problematic matching result? Thanks a lot.
Firstly, here is the matching result using a GPS trajectory file (with id, geog, timestamp) and a connected network (with id, source, target and geometry). In the image below, four road segments (109274, 49166, 109198, 109197) are connected at node 245090. The cpath returned by fmm is {109274, 49166, 109198, 109197}.
However, the actual traversed path should only include Segment 109274 and Segment 109197. The original GPS locations are shown in the image below: I wonder the reason that the returned cpath includes Segment 49166 and 109198. I tried to adjust the parameters. This part of cpath still did not change. Here are the parameters I used for the current matching result:
Is it possible that the problem is caused by some errors in the input data or unsuitable values of the parameters? Many thanks.