Skip to content
This repository has been archived by the owner on Mar 1, 2021. It is now read-only.

Divide measurementErrorSigma into its separate functions #175

Open
neilireson opened this issue May 1, 2020 · 3 comments
Open

Divide measurementErrorSigma into its separate functions #175

neilireson opened this issue May 1, 2020 · 3 comments

Comments

@neilireson
Copy link

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:

  1. as filter in filterGPXEntries
  2. to determine radius from GPX entries to select candidates in findNClosest
  3. 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).

@beauof
Copy link

beauof commented Jul 31, 2020

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?

@neilireson
Copy link
Author

As a work around...

Copy the MapMatching class -> MyMapMatching

add the variables with their getters/setters

private double minDistanceBetweenObservations = 50.0;
private double searchWithinRadius = 50.0;
private double emissionProbabilitySigma = 50.0;

public void setEmissionProbabilitySigma(double emissionProbabilitySigma) {
    this.emissionProbabilitySigma = emissionProbabilitySigma;
}

public void setMinDistanceBetweenObservations(double minDistanceBetweenObservations) {
    this.minDistanceBetweenObservations = minDistanceBetweenObservations;
}

public void setSearchWithinRadius(double searchWithinRadius) {
    this.searchWithinRadius = searchWithinRadius;
}

Then replace the use of measurementErrorSigma in the relevant methiods

minDistanceBetweenObservations -> filterGPXEntries()
searchWithinRadius -> lookupGPXEntries()
emissionProbabilitySigma -> computeViterbiSequence()

Hope that helps.

@beauof
Copy link

beauof commented Jul 31, 2020

Sure helps, thanks! But it would be great to know if GraphHopper will consume this feature in the future / soon.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants