confusing map matching results & errors about barefoot HOT 7 CLOSED

You're using the online map matching results. If you don't need real-time map matching, just use the Matcher.mmatch() method which does the full map matching and outputs the "final" result. If you really need online map matching, you're doing it right but could optimize it. (Let me know, then I can explain it.) I would at least give the mmatch method a try and see the result to check if the roadmap is okay (no roads missing from map import, no false oneways etc.)

Hint: You can use MatcherKState.toGeoJSON() to output the result in GeoJSON and see the result on geojson.io. For that purpose, just replace the KState by MatcherKState in your code. (I need to update the API description in the readme. :) )

The rationale for using the offline map matching results is that it fully exploits knowledge of the full track, whereas online map matching only uses the knowledge it gained "so far" for each iteration of map matching.

from barefoot.

Thanks for such a quick response. Matcher.mmatch() still does emit Filter: HMM break - no state transitions few times and the resulting match still contains multiple identical successive points. This is the geojson response from the map matching

https://gist.github.com/raethlo/bb374ac8a38882eb759c35cb870e0a6d?short_path=4f84da5

from barefoot.

An HMM break with "no state transition" shows that something is wrong with the road map. Is it possible that you send me a sample track (via email if you like)? I can test the import without sample track, but to fully check what's wrong it may help.

from barefoot.

I thought that might be the case, sure this is the short trace I was running the matching with. As for the map data I have imported .pbf for Vienna,Austria from https://mapzen.com/data/metro-extracts/ (I have tried importing the whole country-sized osm export , but the issue persisted).

Thanks a lot for help

from barefoot.

Okay, I think I found the problem: I guess you use the timestamps in seconds epoch time, however, the library expects milliseconds epoch time. Since the matcher uses the time intervals to calculate transition probabilities it experiences distances too far for the low time intervals and detects HMM breaks.

My output with corrected timestamps using the stand-alone matcher is this:

from barefoot.

🙈 I can't understand how I could not have noticed that, I have literally spent days on trying to figure out what is wrong with the street graph. Thanks a lot for help, I owe you a 🍺

from barefoot.

👍 Feel free to come to Munich for that purpose and also for presenting your thesis. I - and also my team - would be interested. Let me know. :)

from barefoot.