Open cyang-kth opened 3 years ago
In case that a trajectory cannot be matched to the road network. The reason could be
If you saw some weird matching result, where the matched trajectory significantly deviate from the original one, the reasons could be
Which algorithm to select?
FMM needs to do the precomputation, which occupies a lot of storage and it may be unsuitable for very big road network. STMATCH does not need precomputation but it is less efficient. You could try stmatch to explore other configurations such as candidate size k, search radius r and GPS error e.
How to select candidate size k, search radius r and GPS error e?
How to select the upper of delta? It depends on the frequency of your GPS data. A large value is needed for sparse GPS data. You can set 3km (if you are using GPS data in unit of degrees, setting the parameter as 0.03 degrees) and enlarge the value if a large proportion could not be matched.
If your GPS data is in degrees e.g., latitude and longitude, your network should also be in degree. The configurations are also defined in degrees:
How about the unit of the output? For example, the error and the offset, do they also need to multiply the 1.132e5 to get the unit in meters?
All units are the same as GPS data and network data.
I am getting the following warning in most of the trajectories.
[warning] [fmm_algorithm.cpp:289] Traj 0 unmatched as points 83 and 84 not connected
which leads to no map matching to the given trajectory. I am using https://github.com/cyang-kth/osm_mapmatching link for network generation. Is it due to data quality? I was looking into HMM algorithm and some research says that "Matching break is a common problem in map-matching, which is mainly caused by trajectory outliers." However, most of the map matching algorithms (graphhopper, Barefoot) uses HMM. Is there any way out for matching which contains a few outliers?
Please let me know.
I am getting the following warning in most of the trajectories.
[warning] [fmm_algorithm.cpp:289] Traj 0 unmatched as points 83 and 84 not connected
which leads to no map matching to the given trajectory. I am using https://github.com/cyang-kth/osm_mapmatching link for network generation. Is it due to data quality? I was looking into HMM algorithm and some research says that "Matching break is a common problem in map-matching, which is mainly caused by trajectory outliers." However, most of the map matching algorithms (graphhopper, Barefoot) uses HMM. Is there any way out for matching which contains a few outliers?
Please let me know.
I am having the same problem with a gps dataset [1] getting eros like
[warning] [fmm_algorithm.cpp:289] Traj 0 unmatched as points 83 and 84 not connected
in almost all cases. This warning returns empty results, i.e. not any matching is performed. I have tried multiple parameters like
_config = FastMapMatchConfig(k_arg=16, r_arg=300/1.132e5, gps_error=50/1.132e5)
but the warning persists. In addition, for the record, my example is based on [2]. In case you want to see the data, I am attaching a few trajectories taken from [1]. Could you please provide some suggestions on how to overcome this problem? Any help is highly appreciated! 1372741036620000446.txt 1372749928620000166.txt
[1] https://www.kaggle.com/c/pkdd-15-predict-taxi-service-trajectory-i
[2] https://github.com/cyang-kth/osm_mapmatching
1372690597620000513.txt 1372692499620000620.txt 1372699631620000667.txt 1372706586620000075.txt 1372709186620000136.txt
Try to smooth your trajectory before performing map matching, it might help. There is also a parameter called reverse_tolerance
, try to set it to 1 to check if it works. @iTsingalis
This page contains a summary of common issues in using fmm.
Firstly, make sure you pull the latest version of the program.
Road network
Road network should be downloaded following the script at https://github.com/cyang-kth/osm_mapmatching. The original network downloaded from osmnx will not work for fmm because
If you use your own network, make sure your network has
The network downloaded from https://github.com/cyang-kth/osm_mapmatching generally satisfies the above requirement.