The optimal route is definitely the fastest one, it follows a large, straight, multilane, divided highway with a high speed limit and very few turns. It is what is produced by OSRM and other OSM based engines.
The default route by contrast has numerous turns, takes a tiny beach road, then a slow small road with numerous cross streets/intersections. This default route has 13 turns MORE than the optimal route.
The optimal route is also slightly less distance than default route so it should be taking it not only for fastest mode but also for shortest mode.
Thanks for providing these example routes, this is indeed helpful. The number of turns is currently not considered for the route calculation (even though it probably should, see also this discussion: Graphhopper takes extra turn).
Still we should investigate why the route with the slow tiny beach road is considered the best. This looks very strange:
The funny looking sample route with a control point you mentioned is correct I believe, there are a lot of one ways around there so its just following those restrictions correctly.
The beach road (Jl Pantai Kuta) and next one in (Jl Raya Legian) are indeed one way also.
Both of the original routes I provided are legit ways to go. Just the optimal one was the very obvious way it should be routing and instead was taking the more convoluted default one. Turn count/time not being considered may very well be hurting a lot of the routing cases I have been finding.
But my optimal route was both shorter distance and faster (by way of a much larger highway with higher speed limit), means that my optimal route really should be the one being found for both “fastest” and “shortest” weighting.
Ok so GH probably takes the beach route instead of Sunset Rd because considering both distance and speed this seems to be the better option. Without taking into account the turn count we would probably need to assume a slower speed for the beach road or a higher priority for Sunsed Rd.
The ‘beach’ road gets a higher speed than the (bigger) Sunset Rd, because GH considers the Sunset Rd to be located close to the city center (where a slower speed is assumed compared to roads further away from the city).
The problem in the Northern part of the route is due to a max_speed=40 tag for Raya Kerobokan. The smaller road (Jalan Mertanadi) does not have a max_speed and thus a default speed is assumed which apparently is higher than the speed for the bigger Raya Kerobokan when max_speed is set. I do not know why this happens yet.
The crossing artifact is correct actually. There is a barrier for a hundred meters of the road at that intersection.
So sunset road maybe should have a higher speed limit or the beach road (or default assumed) a slower speed. I don’t even know though if/what the official limit is there. They don’t really have limit signs posted anywhere here AFAIK.
But if GH considered turn time penalties for “fastest” weighting certainly it would correct the issue and make it prefer the Optimal route like OSRM does. Do you know if there are any plans to implement that? Even a crude implementation like adding 30 seconds to duration for each instruction point (turn or not) would probably fix a huge number of these routes. (I do see many of them, this was just 1 example.)
What I still don’t understand is that it makes the same default route with “shortest” weighting. Surely the meaning of “shortest” is strictly that it finds the route with the shortest distance and shouldn’t consider turn times, speed limits, road type or anything else. And yet my Optimal route was about 1km shorter distance than the default it produced.
Yes this might fix some issue, but the question is what new issues this will create. But yes more accurate turn (and street-crossing) costs are certainly on the agenda, especially for large vehicles like trucks.
This is not so easy to do because the instruction points are only determined after the route has been calculated. And adding 30seconds at every junction would lead to unrealistic travel times. But if you have some more interesting examples feel free to share them, this kind of input is very helpful when trying to improve things like this.
Again, how did you calculate the “shortest” route? I do not think this is supported for graphhopper.com/maps.
I am evaluating the GH API to replace another OSM based service for use in an existing commercial application which I produce. So I already have it integrated for testing purposes and am able to test the Shortest route option. So far I am pretty happy with GH, but this issue of not minimizing the number of turns for a Fastest route seems to be causing a lot of non-ideal routes.
I will try to get back to you soon with more examples.
