Improve matching for oneways

[ghost]

I'm trying to map match the following route - it is a series of lat-lon-time triplets taken at 1 Hz.

After I put them through graphhopper's mapmatching software, I get the following output:

As you can see, there are a bunch of points on the right that are returned by graphhopper that are not in the route that was inputted. What I believe happened was a trip was detected to occur on the opposite end of the street, so graphhopper returned the closest shortest way to get from one side of the street to the other, hence the extra points. Is there anything I can do to reformat the data I input so this does not occur, otherwise what can I do to detect when this occurs (other than looking at its output)?

I'm also running into a problem with another route. The route I'm using looks like this:

The points that I am getting back look like this:

I double checked the order in which points were inputted in my route - the first point is on the bottom left and continue on to the top right as they are inputted. The result that graphhopper is returning starts at the end of my trip (top right), and ends on the bottom left. I'm not sure why this is happening and I've tried reversing the input of my data and am getting the same result. Does anyone know why this is happening?

[karussell]

Thanks, for the detailed screenshots and description. In order to look more closely into it we would need some example GPX files that you use as input.

The last example looks like there are problems with one-ways in the road network but again: hard to debug if one doesn't have the coordinates.

[ghost]

Would it be possible for me to send you the GPX files? If so, what would be the best medium?

[karussell]

Best would be to use gpsies.com - there you can visualize them. Or use any file hoster

[ghost]

Thanks a bunch: Here are the tracks:
http://www.gpsies.com/map.do?fileId=ypuvgrmbyqmyjnad
http://www.gpsies.com/map.do?fileId=bqmpkljzzbijswhb

[karussell]

The first example works with the latest master now.

The second example seems to be in reverse order and produces indeed a wrong match (as the algorithm cannot follow the oneway in the wrong direction it produces artifacts). But on GPSies.com there is a 'Reverse track' option which improves the match but still not like intended I guess.

Will have a look when I improve other matching stuff.

[karussell]

Related to #63

[michaz]

The second example seems to be in reverse order

What makes you think so? It even has time stamps.

[karussell]

What makes you think so? It even has time stamps.

Oh, this is a bit old and I cannot remember exactly. But likely it was against several of these oneways in the map (maybe they were wrong at that time and are fixed now, but you can still see the old status as there are a few arrows on the screenshot)

[michaz]

Maybe they were walking.