| Forum | GitHub | Maps | Blog

Map MatchResult to GPXEntry


I’m searching for a way to map the MatchResult to all inputed GPXEntrys.

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 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.

Time stamps in match result, what is the proposed way for implementation?

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.

Thanks :slight_smile: !


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 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 MostLikelySequence to EdgeMatches. Should I submit a new issue?


Yes, please submit a new issue then!


Alright, here it is


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, (33.3 KB)