search

bmwcarit / barefoot

Java map matching library for integrating the map into software and services with state-of-the-art online and offline map matching that can be used stand-alone and in the cloud.
Apache License 2.0
665 stars 186 forks source link

Question about how many points would be returned in offline map match #103

Closed imtypist closed 6 years ago

imtypist commented 6 years ago

Hi, I want to know about that why does there exist some cases, which the number of input points is not equal to number of response points in offline matcher server. Are they not one-on-one relations? Could you explain this situation for me? Thank you!

smattheis commented 6 years ago

In short, it's often necessary to clean the data because some samples simply don't make "sense" (to the map matching algorithm). For details, please check this comment: https://github.com/bmwcarit/barefoot/issues/92#issuecomment-371743778 Does it answer your question? If it's still unclear, please do not hesitate to ping me again. I will leave the issue open for that purpose. Feel free to close it once you feel that the question is answered.

imtypist commented 6 years ago

Ok, I can understand it, thank you~ But I found another strange thing, just as following, a returned point (not the first point) lost its route attribute, what's wrong with it?

...
{"route":"LINESTRING (104.09960960734922 30.70592250329085, 104.0996308 30.7058862, 104.09966290476181 30.705830543062604)",
"road":5310,"heading":"forward",
"frac":0.013217474897863223},
{"road":17840,
"heading":"forward",
"frac":0.7255559289754527},
...
smattheis commented 6 years ago

Can you please provide the respective input data? Also, which output format do you use?

imtypist commented 6 years ago

Of course, the output format is slimjson. The input data file as follows: 1.txt Its corresponding output file as follows: 1.json.res.txt You can find the lost attribute case above in this output file, it's the 81st element.

smattheis commented 6 years ago

Thanks, that looks like an "HMM break", which means that the matcher couldn't find any route/transition for two consecutive samples as in your input data for the 80th and 81st (edit: of course not 80th and 81st, but 81st and 82nd) samples. To confirm my assumption, please check the console output of the matcher, if it mentions an HMM break for exactly this trace. If that is the case, there is not that much that we can do except for fixing the map data or the road type configuration (which can be quite difficult and depends on country specifics and map data quality).

imtypist commented 6 years ago

Yes, it does mention an HMM break, no state transition. ok, I get it. Thank you for your reply, it's very nice of you~