Graphhopper Car Fastest Encoding sometimes considers other side of trunk for routing

Open Source Routing Engine
1

I’m trying to set up a correct usage of a Car Fastest encoding, the route is getting generated pretty fast. However, when I try to compare the results with Google Maps, the route generated by Graphhopper considers other sides of the trunk when generating the route, which makes a lot of undesired and unnecessary turns.

Capture.PNG815×806 111 KB

This can be seen in the image above, is there any config that I may have missed? If not how do I avoid these cases?

P.S. my config btw:

    GraphHopper hopper = new GraphHopperOSM().forServer();
	hopper.setCHEnabled(false);
	hopper.setMinNetworkSize(200, 200);
	hopper.setDataReaderFile(loadPath);
	hopper.setGraphHopperLocation(savePath);
	hopper.setEncodingManager(new EncodingManager(new CarFlagEncoder(5, 5, 1)));
	hopper.importOrLoad();

	GHRequest req = new GHRequest(startlat, startlon, endLat, endlon).setWeighting("fastest").setVehicle("car")
			.setLocale(Locale.US);
	GHResponse rsp = hopper.route(req);
2

This is because of the way trunks and motorways are stored in OSM, see for example this motorway:
One-way and One-way. GraphHopper matches the closest edge to your request. You have to place the waypoints on the correct side of the road. The same happens for Google Maps as well, btw. Here is one example.

Best,
Robin

3

I did not add the waypoint, actually. The route is generated using graphhopper. I tried out part of the route in Google maps. Maybe it did that cos I added a custom weighting where I added some weight for certain edge IDs so that they are preferred?

4

Below is the custom weighting method:

@Override
	public double calcWeight(EdgeIteratorState edge, boolean reverse, int prevOrNextEdgeId) {
		double speed = reverse ? flagEncoder.getReverseSpeed(edge.getFlags()) : flagEncoder.getSpeed(edge.getFlags());
		if (speed == 0)
			return Double.POSITIVE_INFINITY;

		double time = edge.getDistance() / speed * SPEED_CONV;

		// add direction penalties at start/stop/via points
		boolean unfavoredEdge = edge.getBool(EdgeIteratorState.K_UNFAVORED_EDGE, false);
		boolean isDesired = desiredIds.contains(gh.getOSMWay(edge.getEdge()));
		if (unfavoredEdge)
			time += headingPenalty;

		double desiredFactor = 1;

		if (isDesired && !unfavoredEdge) {
			desiredFactor = 0.3;
		}
		return time * desiredFactor;
	}

I have osm ids in the desiredIds set, I am multiplying a factor of 0.3 to the time to favour that particular osm Id.
I feel there is something that I am doing wrong here. Could someone point out what exactly am I missing?

5

As I said, for me it looks like you placed the waypoint on the wrong side for this trunk. You can always compare your route results with https://graphhopper.com/maps/. If this does not happen for GraphHopper Maps you might have done something wrong with your setup. I cannot see a bug in your weighting.

6

I am not sure if I get what you mean here. I only have a start and an end coordinates…

7

Hi,

in this case you might have placed the start or end on the wrong side of the trunk. Without providing us with an actual sample on GraphHopper Maps that shows this behavior I am afraid I cannot really help you.

Best,
Robin

8

I am basically using google maps to display the route and I generated the route from Graphhopper and filtered 20 coordinates so that they are linearly spaced and can be routed using google maps. Below is one such exapmple:

https://www.google.de/maps/dir/‘47.614278032204766,8.232056347252199’/‘47.63953848122519,8.243880418923805’/‘47.65437333258331,8.232139048698672’/‘47.6706034914539,8.19469373363317’/‘47.67632162592534,8.173669498570327’/‘47.69832728873925,8.14559366134391’/‘47.73746686587036,8.163144435654829’/‘47.753423215897904,8.166872147475306’/‘47.77316315710164,8.181704204865639’/‘47.79966952949024,8.197067861193446’/‘47.82287957868456,8.16962178430606’/‘47.850670431196775,8.12375358768747’/‘47.86669718921253,8.096140431526463’/‘47.8790342333697,8.128221887235833’/‘47.9080955961666,8.164991620890609’/‘47.93119034762361,8.181601014322066’/‘47.96099602343878,8.152700025276095’/‘47.990560859230776,8.160895664115898’/‘48.02146922099894,8.197339434862274’/‘48.03834087487327,8.177113529528235’/‘48.05487688008421,8.204478581349818’/@47.7562123,8.1104807,11.91z/data=!4m85!4m84!1m3!2m2!1d8.2320563!2d47.614278!1m3!2m2!1d8.2438804!2d47.6395385!1m3!2m2!1d8.232139!2d47.6543733!1m3!2m2!1d8.1946937!2d47.6706035!1m3!2m2!1d8.1736695!2d47.6763216!1m3!2m2!1d8.1455937!2d47.6983273!1m3!2m2!1d8.1631444!2d47.7374669!1m3!2m2!1d8.1668721!2d47.7534232!1m3!2m2!1d8.1817042!2d47.7731632!1m3!2m2!1d8.1970679!2d47.7996695!1m3!2m2!1d8.1696218!2d47.8228796!1m3!2m2!1d8.1237536!2d47.8506704!1m3!2m2!1d8.0961404!2d47.8666972!1m3!2m2!1d8.1282219!2d47.8790342!1m3!2m2!1d8.1649916!2d47.9080956!1m3!2m2!1d8.181601!2d47.9311903!1m3!2m2!1d8.1527!2d47.960996!1m3!2m2!1d8.1608957!2d47.9905609!1m3!2m2!1d8.1973394!2d48.0214692!1m3!2m2!1d8.1771135!2d48.0383409!1m3!2m2!1d8.2044786!2d48.0548769

If you check near the “Höchenschwander Str., 79837 Häusern” the point is placed on the wrong side of the trunk. It was the route that I got.

9

Google Maps does not use OpenStreetMap data. Therefore, the coordinates might be slightly different for both systems.

1 Like