Enable GPS-precise map matching

[MK-42]

Added Fetching of wayGeometry on the virtual edges at start and end of the gpxTrack. Closes #50

I don't know if you have any special code-formatting constraints as line length. Could change that if needed.

What do you think about that approach

[karussell]

Thanks & Looks good.

Now only the web module needs to implement and use this too. Also I would like to hide this somehow from public usage in MatchResult, hmmh, not sure how.

[karussell]

Ah, maybe we add a 'getWayGeometry' method to EdgeMatch and do a fallback if non-existing?

PointList getWayGeometry() {
   if(geometry != null)
      return geometry;
   else
      return edgeState.fetchWaygeometry(0);
}

Then we can change the web API from:

PointList pointList = edgeMatch.getEdgeState().fetchWayGeometry(emIndex == 0 ? 3 : 2);

to

PointList pointList = edgeMatch.getWayGeometry();

[MK-42]

done i think. Much smoother to use now. good idea!

[MK-42]

but i forgot the change in the web service. will push that next
btw: doesn't the Console-Version need that change too to be gps precise?

[MK-42]

did some more changes to make using easier. What do you think @karussell ?

[karussell]

here I would use the same naming 'fetchWayGeometry' as in the edge interface because it is also here not always a cheap 'get' (?)

[MK-42]

Any Idea to make that more clever than that? I don't really like it, but as we have the continue in the calling code, we need that piece of code two times...

[MK-42]

sorry, had wrong indentation settings and messed it up a little bit.

I think I've adressed your points. The setWayGeometry part is not that nice in the phase 4, because we need it two times and i didn't want to duplicate the conditions... but extracting that is also not that nice because of the index-params.

What do you think?

[karussell]

I think I've adressed your points.

Thanks!

Looks now indeed better. Will investigate (after next week) why there is the time difference and how to improve this "The setWayGeometry part is not that nice in the phase 4"

sorry, had wrong indentation settings and messed it up a little bit.

No problem

[karussell]

These differences in time should come from the edge vs. virtual edge and normally should be fixed with these changes here. A bit strange.

Now after a bit thinking and struggling I think it is more valuable to merge #49 before or merge both at the same time. I'll let you know once this is done (hopefully in the next 2 weeks) - thanks a lot for this change!

[MK-42]

Anything i can do to get that merged an in the next Release (i think there is an upcoming. Right?)
Then I could also Test the hmm stuff.

[karussell]

Anything i can do to get that merged an in the next Release (i think there is an upcoming. Right?)

Sorry, the release is already kind of out. But will make a merge afterwards and hopefully the next release won't last long. Currently we plan to release more often and delay the features instead of delaying the release with planned features.

I also hoped that I could this working within the release but it would have taken too long. The hmm stuff needs some more tuning and will include it but make it optional to allow a fallback to the old algorithm ... this all makes it a bit more work than currently done.

[karussell]

I stumbled over a new problem where also in-between edges needs this GPS precision, not only start and end. E.g. a tracked truck delivers a dead end road and needs to go forth&back.

[karussell]

The "hmm" work is now better integrated and I would like to push this issue forward now. @MK-42 Would you have some time to invest in this issue soonish? Otherwise I'll have to move this to another version/release.

[aminefalek]

Hello guys, I would like to use this precise map matching feature. I thus downloaded different versions that correspond to the changes you are talking about here. To be precise, I downloaded and tested the following versions:

https://github.com/graphhopper/map-matching/tree/9606f2fc28f7b0d801e97a5e36f830014a147d85
https://github.com/graphhopper/map-matching/tree/7005e9c901788e7aed862e78cb6499946daddf58
https://github.com/graphhopper/map-matching/tree/2cef7f298c9f44f1a294a91eb3d5b7dc283fe009

All three versions returned the same result (which isn't precise), that can be seen here:

The gpx file I am using as input is this one: 120+00085_13643.zip

I am probably doing something wrong, can you please explain what I should do to get it working ?

[michaz]

Fixed this in e380cef (by doing less work: concatenating the Paths returned from map-matching instead of reconstructing a new one (where the begin/end-splits are missing))

[karussell]

Really cool - thanks a bunch!