Error: No edge matched found for submitted track

Dear community,

I am new to Graphhopper, so hopefully, my problem is a trivial one. Working in south-western Germany, I use karlsruhe-regbez-latest.osm.pbf as my datasource and have the tried to match the test.gpx file attached below. I converted the GPS-coordinates that I had with the GPS-Visualizer into the .gpx file presented below.

I do not understand why the algorithm does not work. What am I missing?

test.gpx:
<*?xml version=“1.0”?>
<gpx version=“1.1” creator=“GPS Visualizer http://www.gpsvisualizer.com/” xmlns=“http://www.topografix.com/GPX/1/1” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd”>
<trk>
<name>test</name>
<trkseg>
<trkpt lat=“49.044084” lon=“8.526027”>
<ele>118.99</ele>
<
/trkpt>
<trkpt lat=“49.043938” lon=“8.525977”>
<ele>119.681</ele>
<
/trkpt>
<trkpt lat=“49.043783” lon=“8.525916”>
<ele>119.976</ele>
<
/trkpt>
<trkpt lat=“49.043614” lon=“8.525844”>
<ele>120.066</ele>
<
/trkpt>
<trkpt lat=“49.043432” lon=“8.525756”>
<ele>119.443</ele>
<
/trkpt>
<trkpt lat=“49.043254” lon=“8.525652”>
<ele>118.607</ele>
<
/trkpt>
<trkpt lat=“49.04308” lon=“8.525533”>
<ele>117.0</ele>
<
/trkpt>
<trkpt lat=“49.042908” lon=“8.525398”>
<ele>117.194</ele>
<
/trkpt>
<trkpt lat=“49.042733” lon=“8.525244”>
<ele>117.303</ele>
<
/trkpt>
<trkpt lat=“49.042549” lon=“8.525076”>
<ele>118.049</ele>
<
/trkpt>
<
/trkseg>
<
/trk>
<
/gpx>

What exactly does not work?

Thank you for the quick reply. Here the full error message:

using /usr/lib/jvm/java-8-openjdk-amd64/bin/java
2017-05-29 13:00:04,481 [main] INFO com.graphhopper.matching.MapMatchingMain - loading graph from cache
2017-05-29 13:00:04,570 [main] INFO com.graphhopper.matching.MapMatchingMain - Setup lookup index. Accuracy filter is at 40m
2017-05-29 13:00:04,576 [main] INFO com.graphhopper.matching.MapMatchingMain - Now processing 1 files
gps import took:0.005263252s, match took: 0.023187973
2017-05-29 13:00:04,647 [main] ERROR com.graphhopper.matching.MapMatchingMain - Problem with file ./test.gpx Error: No edge matches found for submitted track. Too short? Sequence size 3
java.lang.IllegalArgumentException: No edge matches found for submitted track. Too short? Sequence size 3
at com.graphhopper.matching.MapMatching.computeMatchedEdges(MapMatching.java:590)
at com.graphhopper.matching.MapMatching.computeMatchResult(MapMatching.java:551)
at com.graphhopper.matching.MapMatching.doWork(MapMatching.java:254)
at com.graphhopper.matching.MapMatchingMain.start(MapMatchingMain.java:114)
at com.graphhopper.matching.MapMatchingMain.main(MapMatchingMain.java:44)

We remove too close points and the result seems to be too small (sequence size 3). Is this a real life match you want to do?

Yes, it is data recorded by a navigation system of a car in time steps of one second. I have taken only a small fraction of the available data to check if it works. I will try it with a longer journey of maybe around one hour then.

Now I have tried it with GPS-data of a journey taking around 14km and 15 minutes. The error message is

2017-05-29 13:36:03,684 [main] INFO com.graphhopper.matching.MapMatchingMain - loading graph from cache
2017-05-29 13:36:03,771 [main] INFO com.graphhopper.matching.MapMatchingMain - Setup lookup index. Accuracy filter is at 40m
2017-05-29 13:36:03,777 [main] INFO com.graphhopper.matching.MapMatchingMain - Now processing 1 files
gps import took:0.09789178s, match took: 0.09341942
2017-05-29 13:36:04,000 [main] ERROR com.graphhopper.matching.MapMatchingMain - Problem with file ./test.gpx Error: No edge matches found for submitted track. Too short? Sequence size 151
java.lang.IllegalArgumentException: No edge matches found for submitted track. Too short? Sequence size 151
at com.graphhopper.matching.MapMatching.computeMatchedEdges(MapMatching.java:590)
at com.graphhopper.matching.MapMatching.computeMatchResult(MapMatching.java:551)
at com.graphhopper.matching.MapMatching.doWork(MapMatching.java:254)
at com.graphhopper.matching.MapMatchingMain.start(MapMatchingMain.java:114)
at com.graphhopper.matching.MapMatchingMain.main(MapMatchingMain.java:44)

EDIT: I attached the original GPS-data (test.txt) and the test.gpx file that is currently causing problems. I ran the test.gpx file through the online software GPS visualizer and it seems to be correct, i.e. a route on an actual German road is drawn.

test.gpx (66.4 KB)

test.txt (20.6 KB)

Strange, when I just upload this to our API I get a match:

Can you verify that you have the correct area imported and use the correct vehicle? Try remove the graph-cache and import again.

Indeed, this seems strange to me as well. I will post the code I type in below. I use ubuntu.

  1. mvn clean
  2. ./map-matching.sh action=importdatasource=./map-data/karlsruhe-regbez-latest.osm.pbf vehicle=car
  3. ./map-matching.sh action=match gpx=./test.gpx

The following also seems very strange to me:
I attached the tour2-with-loop.gpx from ./matching-core/src/test/resources. It can be matched even when I do not import the area of Leipzig! So if above, I do the steps 1 and 2 and then I match tour2-with-loop.gpx, it works and a result file is produced.
In the also attached “tour2-with-loop_karlsruhe_data.gpx”, I replaced the GPS points from Leipzig to Karlsruhe and the program produces the same error that no edge matches could be found. So it seems like the area of Karlsruhe is not imported correctly?

tour2-with-loop_karlsruhe_data.gpx (1.3 KB)
tour2-with-loop.gpx (1.3 KB)

Here I meant: rm -rf graph-cache

It can be matched even when I do not import the area of Leipzig

Highly likely that you have leipzig already imported and not cleared the graph-cache folder … we should throw an exception if one tries to do so probably …

Yep, that was the error. If there is an option to mark the question as solved, we should do so. Basically, there was a typo in my code in point 2 (…action=importdatasource=…). The algorithm said BUILD SUCCESS nonetheless, but it did not rebuild the graph cache, which I realized when you wrote it. That was indeed the reason why the Leipzig files still worked, since it seems the typo occurred after the first couple of tests…

Thank you :slight_smile:

1 Like