I’m searching for a way to map the
MatchResult to all inputed
The comment in the example says:
// return GraphHopper edges with all associated GPX entries
List<EdgeMatch> matches = mr.getEdgeMatches();
But if I try this, only a few of the
GPXEntrys will be mapped successfully
for( EdgeMatch match : matches )
int internalEdgeId = match.getEdgeState().getEdge();
for( GPXExtension gpxExt : match.getGpxExtensions() )
GPXEntry gpx = gpxExt.getEntry();
// map gpx -> internalEdgeId
match.getGpxExtensions() is often only of size 1, ergo only one
GPXEntry per edge, but my raw data contains dozens of gpx entries. This would be no problem if every edge contained at least 1
match.getGpxExtensions() can be empty, too.
The mapping itself is working perfectly. If I draw
mapMatching.calcPath( matchResult ).calcPoints() it has no gaps and is matched like expected. But I need the
internalEdgeId for every
GPXEntry I have inputed.
This seems odd and should not be. Maybe you would have time to debug this a more deeper?
Also if it turns out to be a bug (what it highly likely is already now) please submit it as a new issue.
So it didn’t miss something and it’s intended that all entered
GPXEntrys are mapped to some
EdgeMatch? Alright, I will take a deeper look.
The plan was that all GPXEntries which we used for matching should be associated to EdgeMatch, yes. But probably we didn’t have enough test cases and this requirement got lost.
By the looks of the current
doWork(List<GPXEntry> gpxList) it’s not intended to associate all
The main reason for this is the filtering of
gpxList by a distance threshold
distanceof(previous, current) > 2 * measurementErrorSigma
Now it makes sense that some
EdgeMatch don’t contain a
GPXEntrys. It’s because the edge/way-segment is shorter than
measurementErrorSigma which is 50 (meters?).
I will take a look at the older implementations.
Edit: Yep, before the change to hidden markov all
GPXEntrys were considered.
Ah, okay. Yes, the are disregarded to avoid too many (superfluous) calculations.
Hmm, I can’t come up with an easy way to associate the disregarded
GPXEntrys during the resolvation of
EdgeMatches. Should I submit a new issue?
Yes, please submit a new issue then!
Did a fix for this get into the latest code base? We are also finding that gpxExtension is returning only a single entry but the source gpx data contains hundreds of points.
As a workaround for too aggressive filtering of input points, I’ve added a gpxFilterThreshold to the existing MapMatching class which is used by filterGPXEntries(List gpxList).
Could someone review the change? I’m happy to submit a pull request if I can be authorized to do so.
TrangMapMatching.java (33.3 KB)