Closed ustroetz closed 9 years ago
Thanks, will look into it! Maybe I should try all those tracks from OSM too ;)
hmmh, it is because maxSearchMultiplier is too small. You can set it to 100 and it will work. I'll have to think about how to guess the maximum weighting better or more robust. I.e. improve this code line
algo.setWeightLimit(customWeighting.getMinWeight(gpxLength * maxSearchMultiplier));
The problem is that if there is no limit for the search you can end up traversing the full graph BUT this limit (=time) depends on the encoder and currently uses the minimum value (maximum speed). Maybe we change how the search is limited or think about a fixed encoder-independend limit like distance / 10km/h
In this example it would have also helped if the bike or foot encoder is used (guessing with smaller max-speeds)
Is there a flag I can use in the command line to set the maxSearchMultiplier and the bike encoder? Or do I have to dive into Java in order to set that?
Yes, you can just specify it as parameter on the command line: maxSearchMultiplier=100 and for the encoder you'll have to change it in config.properties BUT this requires a re-import (necessity to removing graph-cache folder), maybe already the first option is sufficient for your task :)
Yeah the maxSearchMultiplier solved the problem. Thanks for the help! Maybe we could add the possible flags to to Readme.
Would you edit (as much as you feel the necessity) and provide as a pull request :) ? All parameters are in the source (MapMatchingMain)
I tried to match this GPX track to the Berlin Metro Extracts: https://www.openstreetmap.org/user/6arms1leg/traces/1744934
I got the error:
Both points are directly on a OSM street. What could be the reason for the error?