Are you trying the latest master? For this try a different gps accuracy … otherwise it can be more tuning effort.
I have tried this with “graphhopper-web-0.7.0-with-dep.jar”
Exist “latest master”-with-dep.jar ?
Yes. In the snapshot repo
Sorry, exist a map-matching-web Snapshot with depency?
Not of the master yet. Will do probably at some point.
I think is the same result e.g.
Without any data I cannot really help. Also for the master you can reduce gps accuracy which should improve it
You can download my (big) test gpx file from BT747 Datalogger fromhere
i have set
not working for < 2
Exeptionjava.lang.RuntimeException: Sequence is broken for GPX with 13198 points resulting in 6446 time steps
Thanks for this, will look into it at some point. Lower than 5m probably does not make sense as it is then too strict and won’t find close roads anymore.
Would you mind to export the wrong matching part above to make it easier debuggable for me?
If this brings something, I like to help. But that need not be, if it does not serve the causal thing.
However, it is intended not only to increase employment.
Yoe can split the original track easy with GPS Prune
Now eg Bereich_1
Download the Gpx
Original Logger track Bereich_1 hier
If it further helps to create very like other areas
As written, there are data loggers with significant deviations.
max bounds: 8.7896095,8.7931582,48.8774418,48.9025076,293.062744140625,465.491027832031
export results to:E:\MyWorkDir\zGPS\matchGPX\output\Bereich_1.gpx.match.gpx
matches: 42, gps entries:296
gpx length: 2988.288 vs 7999.0723
gpx time: 590.0 vs 2596.77
max bounds: 8.9503978,8.9815632,48.9147024,48.9320946,192.94815063,245.31054688
export results to:E:\MyWorkDir\zGPS\matchGPX\output\Bereich2.gpx.match.gpx
matches: 158, gps entries:417
gpx length: 4384.4155 vs 15973.547
gpx time: 832.0 vs 6157.294
Currently investigating this and will be part of the test suite once this is fixed so that it does not occur again.
I’ve investigated this and it turns out this was mainly a wrong
gpx_accuracy problem. If you increase this value now you’ll get a perfect match:
If you keep it low the algorithm does only find close edges and will route you there.
Keep in mind that there were several problems which made the specified gpx_accuracy != the used one, all of them are now fixed in master and you can import the area and do the matching via the new frontend.
thanks for your response. Now my very bad Gpx LogFile works very well with “mapMatching.setMeasurementErrorSigma(100);”
I have a pure local system with “OAM” Maps and it is very hard for me to build this from soruce (Intellij) without maven. I do not know how to import the project without restructure in Intellij and build without Maven.
I hope and wish you make a Snapshot jar file …“map-matching-web-xxxxxx-jar-with-dependencies.jar”
Thank you very much
Nice to hear this!
Regarding the snapshot: you can build this locally - it is just
mvn clean install -DskipTests=true and then you should be able to refer to the installed jars via version 0.8-SNAPSHOT, also have a look at this issue - ie. it is in the works
but my testsystem is a pure local system (no virus) without I_Net connection. Thanks for the hint.
so i have this (Download Errors)…
INFO] Scanning for projects…
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR] The project com.graphhopper:graphhopper-map-matching-parent:0.8-SNAPSH
ap-matching-master\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not transfer artifact org.sonatype.
mvn --projects hmm-lib -DskipTests=true install mvn --projects matching-web,matching-core -DskipTests=true install assembly:single
on some machine with internet and copy the file(s) to your offline machine
i have inserted a OAM map in your WebApp with the MOBAC (local)Tileserver.
How start your MapMatchServer local?
i have a Bike2WeightFlagEncoder track match (setMeasurementErrorSigma(50)) with minor abnormalities FYI (see Snapshots).
green Bike Track (Douglas Peuker)
red match Track with minor abnormalities
2016-08-27 1250__20160827_1250_Rutesheim_rtw_4.gpx.txt (39.1 KB)
2016-08-27 1250__20160827_1250_Rutesheim_rtw_4.gpx.match.gpx.txt (175.0 KB)
Yes, I observed similar for bike2 as it does not prefer the ‘fastest’ and sometimes introduces some obstacles. Probably try
racingbike which could be better. Furthermore those ‘single-branch’ problems (e.g. first screenshot) should be improved on our side, or try setting higher measurement error.
The last problems seems to be oneway problems, please try matching via a different direction, also see this issue: https://github.com/graphhopper/map-matching/issues/63