You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 1, 2021. It is now read-only.
As far as I can understand the code there are two main parameters that allow control of the map-matching (Viterbi algorithm) process; measurementErrorSigma and transitionProbabilityBeta.
transitionProbabilityBeta is used to compute the exponential PDF to determine how the difference between the linear and path distance influences state change.
measurementErrorSigma is an uber-parameter which is used for three different processes:
as filter in filterGPXEntries
to determine radius from GPX entries to select candidates in findNClosest
defines standard deviation to compute normal PDF to determine how the distance between the GPX entries and candidate point influences state change.
I would argue that the last of these is the only true meaning of the parameter and acts as a direct counterpoint to transitionProbabilityBeta (infact emissionProbabilitySigma would be a more accurate description of this function).
Usage 1. (discussed in #64, #92 and associated issues) and 2. (discussed in #65) relate more to the amount of processing that is required to determine the map-match. In particular the combining of usage 2. and 3. means it is not possible increase the radius of candidates without flattening the normal function, this can lead to proximate candidates not being selected unless transitionProbabilityBeta is increase for these specific cases.
Separating these three parameters allows for fine-control of the map-matching process and with this control I can get far more accuracy, albeit at the expense of processing time. Placing this control in the hands of the user is a very good thing and makes GraphHopper map-matching much more effective and configurable for specific use cases.
If you wish I can create a PR (the changes a relatively straightforward).
The text was updated successfully, but these errors were encountered:
I have a use case where I need more control over filtering the GPS locations and finding candidates, as described in this issue. Any plan to merge the commit by @neilireson? Possibly in the next patch version?
As far as I can understand the code there are two main parameters that allow control of the map-matching (Viterbi algorithm) process; measurementErrorSigma and transitionProbabilityBeta.
transitionProbabilityBeta is used to compute the exponential PDF to determine how the difference between the linear and path distance influences state change.
measurementErrorSigma is an uber-parameter which is used for three different processes:
I would argue that the last of these is the only true meaning of the parameter and acts as a direct counterpoint to transitionProbabilityBeta (infact emissionProbabilitySigma would be a more accurate description of this function).
Usage 1. (discussed in #64, #92 and associated issues) and 2. (discussed in #65) relate more to the amount of processing that is required to determine the map-match. In particular the combining of usage 2. and 3. means it is not possible increase the radius of candidates without flattening the normal function, this can lead to proximate candidates not being selected unless transitionProbabilityBeta is increase for these specific cases.
Separating these three parameters allows for fine-control of the map-matching process and with this control I can get far more accuracy, albeit at the expense of processing time. Placing this control in the hands of the user is a very good thing and makes GraphHopper map-matching much more effective and configurable for specific use cases.
If you wish I can create a PR (the changes a relatively straightforward).
The text was updated successfully, but these errors were encountered: