Due to site maintenance, Forum interaction has been disabled until August 13. For support, please search existing forum posts or check the support page.
Fast routing is not fast
Routes created don’t seem to be fast when compared to staying on a highway from start to finish. I’ve uploaded two screenshots where the start and end are on a stretch of highway that would normally take nine minutes to navigate. Instead scenic, regardless of the mode takes a trip throu
gh the city with tons of lights. In one case I forced the app to take a via still on the highway that shows the correct routing while the other let the app add six minutes which seems to be the shortest path, not fast or efficient.
where this most painful is when navigating to a route start (when the route is not forced by via)
I’m aware of the issue and in contact with routing provider about it. I recommend to not use fast routing for now, but in stead use efficient. I do not have control over short and fast modes. That’s all 3rd party routing framework. I do have some control on efficient.
if provider doesn’t come through soon I probably will make fast the efficient mode in background and remove efficient mode.
Guido, the routing method does not appear to impact the route in this case. Even in efficient mode, the app wants to leave the highway and traversing intersections, taking a longer time over a shorter distance. As you can see from the screenshots the longer route is materially less time because it does not go through the city streets.
I see what you mean. Sorry...should have looked more careful first time around. I've now taken a look at the source of the map data (OpenStreetMap). It seems that the data is the cause of the wrong routing. Wrong road classification and missing max speeds to be precise. Here's how OSM itself routes:
As you can see it's the same as Scenic.
The way routing in Scenic works (for fast and efficient):
- It takes max speeds of roads and together with distance it calculates the 'fastest' route. Time at intersections is not taken into account!!! (Sorry...that's something I can not change)
- The difference between fast and efficient is that, for fast, it takes max speeds from the map data (and if unknown it takes an arbitrary value which I don't know and can't control either.
- For efficient it looks at the road classification (comes from map data too) and uses a max speed from a table I can configure (max speed per road class per country). There are about 20 road classes.
Knowing this...now take a look at speeds and road classifications of the roads it is suggesting:
The roads are marked as secondary and even primary roads. Primary roads are normally roads just below highways...with a high max speed and secondary roads is the class just below that. And...since the distance of this route is quite a bit shorter... Scenic thinks this is the faster route.
Long story short... I can't really change this. Well... for efficient mode I could lower the speeds for primary and secondary roads, but that would mess up a lot of other routings in other areas where road classifications are done correct.
I will suggest an edit for these roads in Open Street Map... and then hopefully it will be corrected when Scenic's framework provider takes a new extract from OpenStreetMap (they do that twice a year).
I know this is probably not the answer you were looking for, but I hope it at least explains.
Wow that is a great explanation. Thanks for taking the time to explain it so thoroughly. If the data is bad, not much to do given the tools at hand.
So yes if the highway/"motorway" are not weighted far enough apart from Primary & Secondary one would see a discrepancy...or some ability to know even the number of intersections on a route (not necessarily time at each). A highway has no intersections, the other route is littered with intersections. Max speed may not be the best indicator of "fast" since stopping mitigates speed by some linear factor of number of delays.
It is interesting that the time quoted on Scenic for the two different routes (one forced with a single via and one calculated) shows the difference in time as if Scenic would know one was faster had it checked that path. If as you say some road is mislabeled the software might not know to check that path in the first place.
I guess the larger providers have historical or realtime data and don't rely on map data so much since there could be all sorts of speed bumps even on a highway. That's where traffic data would be useful I suppose for Fast/Efficient.
thanks again Guido!
Bill
Another example of odd timing in efficient mode is a route where the track is the same but the timing is vastly different. The route is https://scenicapp.space/route/wSDHFEQx
The same route takes 30 min using Efficient and over hour in Fast and Short.
Yes. I'm actually looking into a new/better map and routing provider for next season. (for many reasons but this is one of them)