Hello,
We intend to use the map mathcing API for getting the type and surface for our MountainBike GPX tracks.
However when a segment is not present on OSM the map matching algorithm seems to force a detour with known routes, hence introducing unwanted behavior for our usage as inexact statistics would be returned.
Would there be a way to avoid this behavior, ie force the map matching “to not match” when no segment is available in OSM ?
Do you have an example for such a segment?
Here is a better view of our proble.
This is the MTB track we have in our Database :
utgtrack-8322(1).gpx (87.2 KB)
When we process it through map matching we get :
utgtrack-8322MM.gpx (48.7 KB)
Which reprensents a change of 18% of the itinerary becaus eht Mountain bikeer decided to follow nonexisting OSM transportation artefacts.
And ends up with 8 additonnal ‘unwanted’ kilometers after map matching.
Do you see an option to lower this type of behavior, knowing our main interest here is to collect data of surfaces and type of trasportation (roads versus tracks) ?
Hi all, I’m encountering the same problem as @utagawal has described here. Did you already implement something in the code that can do this or do you know of an easy way to implement this myself? Thanks in advance!
One of the option we are exploring is to split our GPX file with couples of 2 points used as segments. Then we make api requests to GH to snap every segment and we rebuild a global GPX file as an answer.
Did you find an other/ better way ?
Can you not first match the path using GraphHopper and then reject it in case the result deviates to a certain degree from the path you when you simply connect your gpx points using straight lines?
That would be a way, but our GPX are coming from Mountain Bikers and sometime for a tiny section of the whole GPX file, the underlaying OSM map is not yet updated. We want to keep these section finding a smart way to do so. (maybe also having a failproof mechanism that they should only be over areas with specific landuse like fields or forests…)
Ok let’s say there is a 20km long route and only a small section of 300m somewhere in the middle is not accurately matched. What kind of response do you expect? Doesn’t the approach I suggested still work in this case? You could compare the matched result with the input points, figure out which parts of the route are far from the GPX points and exclude them for your calculation of the surface statistics for example.