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 GPXEntry but 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.
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 GPXEntry to EdgeMap.
The main reason for this is the filtering of gpxList by a distance thresholddistanceof(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.
Hmm, I can’t come up with an easy way to associate the disregarded GPXEntrys during the resolvation of MostLikelySequence to EdgeMatches. Should I submit a new issue?
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.
Thanks,
TrangMapMatching.java (33.3 KB)