GPS-Precise start end endpoints for mapmatching

Open Source Routing Engine Map Matching
1

Continuing the discussion from How to expand a matched trip along the graph:

Maybe I should start a new topic, because it’s a different problem:

If I use the current MapMatching master I get a (in my opinion) wrong matching.
See input and output gpx (merged together as diffrent tracks) here: https://gist.github.com/MK-42/ee07e8ffd2f55507b5fabd3fb35c5e66#file-wrongmatchedtracks-gpx

If i visualize that with i.e. www.gpsvisualizer.com one can see, that the matched path is longer in both ways, it is expanded to the next tower-node in the graph I think.

How to get a match, that is starting and ending as close as possible to the start and endpoints on the road?

Thanks for all your support!

Edit:
I think the unitTest MapMatchingTest.java::testDoWork() even prevents this beheviour. It checkes if the result doesn’t contain virtual edges. To have correct start end endpoints that would be needed I think. What is your opinion on that? Any way to get the behaviour?

2

I think this is intended, although we should probably return the last full edge instead of removing it.

The problem is that we can only return real edges (which go just from junction to junction) and virtual edges are of temporary nature so we cannot return them here:

link.put("id", edgeMatch.getEdgeState().getEdge());

To fix the problem you are having we should return always original and ‘full’ edges (AB, BC, CD) and the full geometry like:
A----x1-----B------C----x2-----D

and additionally provide a parameter where the geometry can be reduced to go directly from x1 to x2.

And you say the current behaviour is that it is returning the inner edges - in this case just BC?

3

And you say the current behaviour is that it is returning the inner edges - in this case just BC?
No, from my understanding AD is returned. At least if you do

map-matching.sh action=match gpx=Tracks.gpx

with Tracks.gpx containing x1x2 you get a path that contains AD back from the program. I don’t know if thats post-Processing, but I couldn’t find anything regarding such a step. So I assume AD is returned from MapMatching.

So as you describe it, the behaviour is as intended.

But I would need to get the mapMatched path x1x2. How to achive that? Any hints?

Edit: geting x1D would be sufficient

4

So you basically would need this:

You would need this as a new feature and for the first call of MapMatching.doWork you have to avoid the code block of the following for the start node now:

replace virtual edges with original *full edge* at start and end

Please open a new issue for this.

5

I would like to work on this. Maybe I can contribute that Code.

How would the geometry be returned? Wouldn’t i need to return the QueryGraph to have the virtual edges accessible from outside?

I could just return all de GPS Nodes until the first Tower node (as i need the correct waygeometry) in a list inside of the queryResult. But I think there could be a cleverer solution?

Edit: will also open the issue soon

6

Yes, virtual nodes & edges should never leave the internals but the reduced geometry could.

How would the geometry be returned?

You would just need to call virtualEdge.fetchGeometry like you do on a normal edge and the virtualEdge is already available in the doWork method as path.calcEdges. Then in the last lines the potentially virtual edges are replaced with a normal edges.

7

For anyone interested in this feature here is the PR from @MK-42