The result of map matching is strange

[visile]

I'm matching private car trajectory data, but the matched path and matched edge index in result is defect。 when I make the visualization of matched point，the result is strange，the yellow points are my trajectory datas，and the blue are the matched points。 Can you tell me where there is a problem?Thank you very much！

[cyang-kth]

I think in that case, you need to check the topology of the network (you can visualize network direction in QGIS), perhaps some direction is wrong at the two yellow points above the rectangle.

[visile]

Excuse me again, I checked the direction of the road network and found that only one direction of any road section was stored before. However, when I changed to a two-way road section(In the attribute table, each road section has two sources and targets), some points still could not match the road network. Is there a problem with my parameter setting? My trajectory data has been diluted to 50m intervalsexcuse. what is more,the matched path and matched edge index in result is still defect.

[cyang-kth]

You need to increase k and search radius to consider more candidates to see if they can be matched.

From current result it is hard to tell what is the issue there.

If you can send me (cyang at kth.se) the road network (perhaps just that part) and that GPS data, then I can have a more detailed look.

Another issue of reverse movement is also one case the algorithm fails to match trajectory. https://github.com/cyang-kth/fmm/issues/98

[visile]

I increased k to 16 and search radius to 0.005,but still have some wrong matches.This is my data(network.shp and gps data) test.zip ,please help me make a test and tell me what is wrong happen.Thank you very much!

[cyang-kth]

@visile The network you generated is not correct.

• ID field should be different for two reverse edge
• Source target fields should be replaced for the reversed one. If one is source 1 target 2, the other one should be source 2, target 1.
• The geometry of the feature should be reversed for the feature. One is LineString(1 1, 0 0, 1 2) the other one should be LineString(1 2, 0 0, 1 1)

If you download the OSM network from https://github.com/cyang-kth/osm_mapmatching, that problem is automatically corrected.

If you are using your own network, you can use Geopandas or PostGIS to reverse the network edges.

[visile]

I'm very sorry, because of my carelessness, the source and target of the reverse edge is wrong. Now it can work normally. Thank you very much for your help! But I still have a few questions for you。 1.What is the appropriate distance between trajectory points？ 2.If there are some missing tracks, can the algorithm match the complete road section？ 3.What is the appropriate parameter k and search radius setting when multiple tracks are matched together。 4.Is fmm better than stmach?If processing the number of points is 97947 and the number of edges is 292790, is FMM feasible 太感谢北交的学长！地图匹配的算法我用了很多个都没有取得那么好的效果，真的太棒了！

[cyang-kth]

I'm very sorry, because of my carelessness, the source and target of the reverse edge is wrong. Now it can work normally. Thank you very much for your help! But I still have a few questions for you。 1.What is the appropriate distance between trajectory points？

If your trajectory points are equally sampled, you can estimate a distance from average speed times interval. The upperbound of UBODT generally depends on it.

2.If there are some missing tracks, can the algorithm match the complete road section？

If two points are extremely far away, exceed the upper bound, then the algorithm cannot match it.

3.What is the appropriate parameter k and search radius setting when multiple tracks are matched together。

Generally k and search radius depends on the accuracy of your observations, for high quality data, maybe several hundred meters could be fine. K could be sent to 8 or 16.

4.Is fmm better than stmach?If processing the number of points is 97947 and the number of edges is 292790, is FMM feasible

FMM should be the same with stmatch in terms of mathematical model. The only difference is FMM adopts precomptuation to accelerate the process. STMATCH does not need precomputation, however, it could be much slower. The graph size of the number of nodes 97947 and edges 292790 is actually acceptable for FMM. You can gradually enlarge the upper bound to ensure that most of the points are matched successfully.

太感谢北交的学长！地图匹配的算法我用了很多个都没有取得那么好的效果，真的太棒了！

不用客气，我把这个开源也是希望能够帮助大家解决类似的问题。