Closed ustroetz closed 9 years ago
In my htmloutput branch I "translated" the cryptic "Cannot extract path - no edges returned?" message into "Probably leaving covered OSM data area?". I usually got this message when the GPX track left the area with covered OSM data.
But this is not the case in your example. I reproduced your example with my map-matching beta release located at (https://github.com/ratrun/map-matching/releases) using a "car" profile with following algorithm parameters:
Algorithm parameters: gpxAccuracy= 15, separatedSearchDistance=250, maxSearchMultiplier=150, forceRepair=true
I got a match but the result is bad:
matches: 191, gps entries:150 gpx length: 10248.322 vs 15462.31 meters gpx time: 149.0 vs 2982.224 seconds
I took a closer look in JOSM at the first obvious loop where the vehicle took the "Rodrigo de Araya", but the match routes back and takes "Celia Solar". Here it looks like an OSM data error as the vehicle is going in the worng side of the oneway at "Celia Solar".
I wrote a blog about the interpretation of the map-matching results at https://github.com/ratrun/map-matching/blob/htmlresultoutput/htmlreport.de.md. Unfortunately in German, because here it is much easiser for me to express these non trivial things.
Thanks @ratrun for the analysis. It seems like there is a one way missing in OSM
Unfortunately I can't trust the data enough to edit it in OSM. So I have to leave it like this for now.
@karussell would it be possible to extent the error message to something more detailed i.e. the error might be related to OSM?
@ratrun Have you thought about integration your html report in the simple-js-ui
? I guess it would require to have map-matching as an API service.
The error can be improved, sure. But I'll have to investigate this first.
@ustroetz About: "Have you thought about integration your html report in the simple-js-ui?"
No. I guess you mean what is called the Grahhopper Tools project and the MiniGraph UI. Actually I have used this just once and forgot about its existence. My goal with the htmloutput branch was to provide the possibility to play around with map-matching to broader "end users", not developers and therefore I wanted to keep it as simple as possible. From what I remember about the MiniGraph tool it was not looking very nice. The htmloutput idea probably was still too complicated. I didn't receive much feedback so far. But maybe it is because I the German description and because I didn't translate it into English.
I actually meant the simple-js-ui
: https://github.com/graphhopper/map-matching/tree/master/simple-js-ui
Maybe you could enable issues in your projects Github repository. Else it is kind of complicated to contact you and discuss the project.
I didn't recognise this, but originally I have tried to use the leaflet file layer. I came to the conclusion that it does not work for real world bigger GPX files. I was only able to open very small ones.
The htmloutput branch is on github, see https://github.com/ratrun/map-matching
The issues on your fork of map-matching are turned off (go to Settings>Issues to turn them on).
Thank you. I turned them on now. I guess this issue can be closed now. I can't do that.
I am get this error for the file posted below:
I am using the santiago_chile metro extracts. Any ideas what might be the reason?
The sample file: