-
Notifications
You must be signed in to change notification settings - Fork 275
Conversation
…f the gpxTrack. Closes graphhopper#50
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. |
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(); |
done i think. Much smoother to use now. good idea! |
but i forgot the change in the web service. will push that next |
did some more changes to make using easier. What do you think @karussell ? |
* inclusive the base and adjacent tower node</li> </ul> | ||
* @return pillar nodes | ||
*/ | ||
public PointList getWayGeometry(int mode){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here I would use the same naming 'fetchWayGeometry' as in the edge interface because it is also here not always a cheap 'get' (?)
…to code-review and set wayGeometry via setter
@@ -500,7 +496,16 @@ public boolean execute(int edge, List<GPXExtension> list) { | |||
return res; | |||
} | |||
|
|||
private boolean isVirtualNode(int node) { | |||
private void addWayGeometry(int i, int lastIndex, PointList wayGeometryToFirstTowerNode, PointList wayGeometryToLastGPXPoint, EdgeMatch edgeMatch) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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...
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? |
…e end point is matched to a tower node, the wayGeometry got overridden. Added also a testcase for that.
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"
No problem |
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! |
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. |
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. |
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. |
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 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 ? |
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)) |
Really cool - thanks a bunch! |
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