Process freezes at different points

[KPollmer]

I'm using the offline map matching for my diploma and it stops working at different points, depending on what i did (preprocessing or not). I have attached a small sample of data, both coordinates and shapefile of. Sample.zip I tried various ways:

• no preprocessing, max_search_distance=40, fast matching type --> process freezes at 1% create backtracking
• no preprocessing, max_search_distance=40, slow matching type -->process freezes at 1% calculate transition probabilities
• clipping network (buffer radius 0,001), max_search_distance=40, fast matching type --> process freezes at 1% create backtracking
• clipping network (buffer radius 0,001), max_search_distance=40, slow matching type --> process freezes at 1% calculate transition probabilities

• clipped network and reduced trajectory density (min distance = 100, without last feature), fast matching type --> process reutrns following statement: get most likely path... Traceback (most recent call last): File "C:\Users/Kevin Pollmer/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\Offline-MapMatching\mm_processing\offline_map_matching_algorithm.py", line 198, in processAlgorithm error_code = mm.startViterbiMatchingProcessing(trajectory_layer, File "C:\Users/Kevin Pollmer/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\Offline-MapMatching\mm\map_matcher.py", line 154, in startViterbiMatchingProcessing vertices = self.hidden_model.findViterbiPath() File "C:\Users/Kevin Pollmer/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\Offline-MapMatching\mm\hidden_states\hidden_model.py", line 151, in findViterbiPath current_id = self.candidates_backtracking[id] KeyError: 14

  Execution failed after 0.24 Sekunden

• clipped network and reduced trajectory density (min distance = 100, without last feature), slow matching type --> process returns following statement: get most likely path... Traceback (most recent call last): File "C:\Users/Kevin Pollmer/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\Offline-MapMatching\mm_processing\offline_map_matching_algorithm.py", line 198, in processAlgorithm error_code = mm.startViterbiMatchingProcessing(trajectory_layer, File "C:\Users/Kevin Pollmer/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\Offline-MapMatching\mm\map_matcher.py", line 154, in startViterbiMatchingProcessing vertices = self.hidden_model.findViterbiPath() File "C:\Users/Kevin Pollmer/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\Offline-MapMatching\mm\hidden_states\hidden_model.py", line 151, in findViterbiPath current_id = self.candidates_backtracking[id] KeyError: 14

  Execution failed after 0.22 Sekunden

During my fails I also got KeyError: 307, but I couldnt reproduce that example.

@jagodki I need some help in solving that problem!

Thank you!

[KPollmer]

Little update: I read the other issues and saw, that the process doesnt freeze. QGIS shows me remaining computing time of 5 hours and more for creating backtracking or calculating transition probabilities.

[jagodki]

Hi,

the attached archive with the sample data contains only the SHP-file, not the SHX- and DBF-files at least. You can also upload the sample data as GeoJSON or Geopackage.

Your problem is related to the calculated probabilities. It seams, that the comparison of the probabilities does not work. Please upload your sample data again with the missing files or in another format. Then I will debug this problem.

Best regards, Christoph

[KPollmer]

I've uploaded the data to my dropbox, because it was to big to insert it here. https://www.dropbox.com/s/u9szvgte95ldcu3/files.zip?dl=0 It is the raw data, like you would have it if you download it from Geofabrik. Please let me know when you downloaded it.

[jagodki]

Thanks for the upload, but unfortunately I am not able to load the SHAPE-file into QGIS without errors. But I downloaded the OSM highway data for the region of your trajectory via the Quick OSM plugin (using the Overpass API).

I had a look into your trajectory. Your geometry data has the CRS EPSG:4326. This is a big problem, because the plugin calculates distances according to the CRS of the input data. Please reproject your data into a metric CRS, e.g. EPSG:25833 for the city of Leipzig.

I tried the following calculation steps:

• reprojection of the network and the trajectory to EPSG:25833
• reduce trajectory density to 25 meters (using the plugin function Clip Network)
• clip the network to 250 meters around the trajectory (using the plugin function Reduce Trajectory Density)
• run the map matching using the following parameters:

Computation time was 228.26 seconds on a MacBook Pro 2018 with Intel i5. The matched trajectory looks good for a first try (no adjustments of the parameters tried):

[KPollmer]

OK, now its working great. I didn't knew that it was necessary to change the CRS for calculating the matched trajectory. But somehow it makes sense. But can you give me a hint what i can do with this kind of matches? My clipped network includes the service-ways close to the points, but the algorithm decides to take the red route. It looks similar to the one on the main-page of this repo

[KPollmer]

I solved the problem above. I have another question: How do i solve problems like this: I already deleted points where i thought they could be troublesome but the algorithm chooses the wrong road and also thinks, the parkinglot on the left is part of the route. And on sometimes it chooses both directions on "Messe-Allee". I'm a bit clueless.

[jagodki]

Sorry for my late response, I did not have a look into it during my holidays.

This is not an easy task. My experience with the plugin and with similar tasks in a former job is to use a node-edge-model for the streets instead of centrelines for each direction and to exclude not necessary road types from your road network (e.g. you do not need bike roads for map matching if you drove on a highway).

Do you have any other data, e.g. from an IMU, or something else? Preprocessing GNSS-points with IMU-data using the Kalman filter will improve the accuracy dramatically.

Otherwise it could be helpful to split your trajectory in multiple parts and run these parts separately. You could stick the matched trajectories together afterwards. Such a workflow can be build with the model builder or via batch processing or directly in python using the processing framework.