Long distance routing behaviour has been abysmally documented, and as referenced by recent Discord discussions, even some senior editors do not have this concept understood fully (or even at all).
This wiki is our place for documentation of all standards in WME with respect to editing, and the expectation that editors should understand these concepts should only occur when it’s actually documented properly.
Now, given that.
We have several references for long-distance routing, however none have adequately explained how this works. It is the hope of this thread that we have a new comprehensive Wiki Article demonstrating this behaviour.
– Proposed New Article – [in progress]
Title: Long Distance Routing
Long Distance Routing is a system that the Routing server uses in respect to route selection in cases where the distance routed is longer than a certain distance. The effect of this is pruning of certain Types of roads, as the distance becomes greater. This limits the burden on the routing server, however it also limits the choices where alternate routes are present in the middle of the route.
Distance Based Routing:
15km from destination/origin: ALL roads are used in route calculation.
20km from destination/origin: PS and above only used for consideration.
30km from destination/origin: mH and above only used for consideration.
That’s the problem, we have no idea. The NZ forum post suggests that only Freeways will be considered, but advice from glomp a few months ago suggest that MH+ never get pruned.
I think that the best way to go about it would be to find strange long distance routes, compare with Google, add alts if a State Route etc, wait until a tile update and compare again. It could be a similar thing with the upgrading of PR to mH.
It appears, from a quick read, that the alt numbers may be bypassing the previously mentioned limits. This could mean that as long as you enter onto the B32 within the 10/20/30km limit, then you can traverse multiple segments outside the 10/20/30km limit, as long as they all have B32 as an alternative name. Where a segment in the middle has both B32 and B70 as alternative names, then the B70 route can continue that distance transit.
This would permit the specific distances to remain the same. If they are increased then the server load goes up exponentially with a lot of extra segments to calculate. It would, however, end up having to calculate through all linked numbered routes (where the linking occurs at the route intersections with the multiple alternative names).
It could work and be implemented, but only if we can get solid confirmation that it is setup to work in the routing server, otherwise a waste of time to go and add the alternate names.
I believe this has to do with naming continuity, and how the routing system handles long-distance routing in respect to that.
There has been a lot of information, misinformation and theories about how naming continuity with routing works. I believe TimAThing did that MapRaid (forgive me if I’m wrong), and he could probably elaborate a little more.
In lieu of that, he did this addition to our local Wazeopedia and updated it based on his understanding of the routing behaviour.
Beyond that I think only the road type has an impact if there is no naming continuity.
This is how I make sense of this, and it seems to fit with what vladimobile (Russian GC who translated that Google doc; original author was MacVit, I believe) told me. He said that name continuity helps the routing server not to work so hard in finding long-distance routes, so it could be the difference between getting a route and getting a server timeout. By the way, based on
I have a few (maybe not ordered) observations:
Long-distance routing has been overhauled with the recent introduction of XL routes into production. According to staff, in ROW this happened about two weeks ago.
I have gotten multiple routes of over 2000 km that leave a freeway for a MH more than 500 km past the start and come back to a freeway a few hundred km later.
One of those routes was from Sault Ste. Marie, MI, to Charleston, SC, and it traversed unnamed ramp segments between freeway and MH in central Ohio (about 800 km into the route).
I was able to get a route from Fitzroy Crossing, WA to Sydney, which is about 5000 km, and it only took about 15 seconds to calculate.
However, from Fitzroy Crossing, although I was able to get a route to Alice Springs, I was unable to get a route to Marla, SA.
So because of all that, I’ll say that the name continuity thing, if it’s still real after the new XL route overhaul, would only help at mH and lower road types. You can test it by creating name continuity on Tanami Rd and seeing if that helps with routing server timeouts through certain very long routes through there. To me, this looks like the classic “lake effect” where Waze has problems with circuitous routes, rather than being caused by the name dicontinuity, but I’m not sure.
However, adding spurious alt names at every interchange is not only inaccurate (unless those ramps truly carry a numbered route) and a lot of work, but it breaks detour prevention, since detours must have name discontinuity from their last segment to the first highway segment after them.
Does that mean that this part of our wiki which states ‘Where the ramp connects two roads that have route numbers, the ramp should have one alternative name with the route number (None for city) for each of the routes. For example, a ramp that connects “M31 - Hume Hwy” to “A23 - Barton Hwy” should have two alternative names, “M31” and “A23”’ is incorrect?
I would recommend testing this alt name scheme somewhere and trying to determine whether it provides any current benefit, and whether that benefit outweighs the cost in extra time, breaking detour prevention, and adding inaccurate information to the map. By inaccurate I’m just saying the alt names are non-factual and therefore a hack, and while accurate information should be prioritized, sometimes hacks provide unique benefits. Someone should see whether these do.
I don’t see this scheme as helpful in my community, but since we assign our road types according to state functional class, there are very few instances here where long-distance routing would benefit from having mH or lower in the middle.
That’s good news! Minyip to Dimboola would be an example of the lake effect (still a problem when getting certain routes around the US Great Lakes), but XL routes is a new method to calculate routes longer than 1600 km. It was first tested in RBS and then released to production in NA a few months ago and ROW a few weeks ago. The info I got about it is from threads on CenterCode in the RBS forum and the routing forum (this forum doesn’t like those long links I guess). Since it’s in production we can talk about it now.
In the app, the route displays in a simplified manner (I think nodes are connected with straight lines), with instructions in the middle of the route not shown until the driver gets closer to them. One of the routing engineers said that routes up to 4800 km are supported. I have been able to get some that are more like 5800 km. However, it doesn’t seem to apply to routes that are fairly long, but not XL, such as routes under 1000 km. At that route length, only mH are an issue for pruning, which is why I’m saying that this alt name thing, if proven to do anything, would only be useful in enabling fairly long routes with mH in the middle.
I have mainly been testing in the app, and by server timeouts I meant “failure to communicate with routing server” messages. In Live Map you may have similar results; sometimes if Live Map doesn’t give me a route there is no spinning, and sometimes it spins for a long time and times out.
I don’t see a big improvement from the name continuity change on Tanami Rd. Still can’t get routes from Halls Creek or Fitzroy Crossing to anywhere south of Alice Springs. However, Alice Springs to Halls Creek works now; I think you said it didn’t before.
ituajr I am not sure I am following the improvements that may have been made but if they are tangible are we able to revert some of the segments that have been increased in priority (that was done to solve some of these long distance issues) back to “unchanged”?
Given that the route works in reverse, I would be looking at other factors. Have you looked at route speeds?
If I am looking at this correctly some of those look quite atypical (100km/hr vs 37km/hr at one point). That is almost triple the time for that segment (8mins vs 25mins).
