I am building an application which - amongst other things - involves a map matching feature.
I have already successfully imported a country’s osm-pbf to Graphhopper and tested it’s map matching service.
First it seemed to work well for my purpose, only until I realized the map matching output was a simplified version of it’s planet_osm_line counterpart. I am not talking about very huge differences, but enough for giving me a headache.
I did my homework, researched and found out the OSM route network gets simplified 2 times: once upon pbf import and once upon output. After my research on the GH forum, I was able to control the output simplification and disable it by setting the necessary parameters in the map matching API, however I am just not able to find out how to TOTALLY disable simplification during data import.
See the screenshot below that would better explain my problem! The original, unsimplified OSM network is marker by purple, whereas the output from the GH map matching service is marked by orange color.
I am aware that it would result in a larger size, and I am totally OK with it. The main goal would be to use the EXACT same edge geometries that are present in the OSM data, since I am doing some analysis with the map matching result.
To be honest, I am a total newb when it comes to Java, but I can adapt fairly quickly so any help on this would be highly appreciated!
/**
* This parameter affects the routine used to simplify the edge geometries (Ramer-Douglas-Peucker). Higher values mean
* more details are preserved. The default is 1 (meter). Simplification can be disabled by setting it to 0.
*/
public OSMReaderConfig setMaxWayPointDistance(double maxWayPointDistance) {
this.maxWayPointDistance = maxWayPointDistance;
return this;
}
These findings lead me to think, that if I manage to figure out the correct parameter name for setting the max waypoint distance, then I could set it to 0 in the config.yml file.
Could you please confirm whether I am on the right track here? Thank you!
Yes, with routing.way_point_max_distance: 0 it should be better but it might have small differences as there could be rounding errors. See Helper.degreeToInt which is called before we store latitudes and longitudes. See this comment before DEGREE_FACTOR:
we keep the first seven decimal places of lat/lon coordinates. this corresponds to ~1cm precision (‘pointing to waldo on a page’)
Thick purple: Original Planet OSM lines
Thin purple: GH generated route after setting routing.way_point_max_distance: 0 and also limiting output simplification by setting way_point_max_distance=0 in the URL
Thicker mustard: GH generated route after limiting output simplification only by setting way_point_max_distance=0 in the URL
What is the scale in these screenshots? The simplification is one thing, but it should only remove some intermediate points. The slight offset would have to be due to rounding ‘errors’, but I wonder why you need the values to be the exact same?
While I won’t be able to tell you an exact scale for now, the offset between the lines is in the sub meter area, which could be totally ignored in most of the use cases.
I was working on a piece of logic that retrieves ALL cross streets on both sides along a planned route.
Perfectly matching lines would have made my life a lot easier, looking for angles in each intersection, but since then I figured out another, promising solution which I am now testing.
Graphhopper remained the source of the map matching, but the difference is in what I am doing with the resulting polyline.
So it should be possible to make the GH coordinates exactly the same as in the OSM input file. Possibly the coordinates are rounded to a lower precision somewhere, I don’t know, but I would consider this a bug then.
Still, I don’t see which kind of application would require to keep the coordinates exactly the same (with such high precision), unless they are somehow used to identify a way or node, but that can probably be done another (better) way.
