Hi guys,
I would like to post a feature request. In Norway, where I live, there’s a lot of tunnels. I’ve noticed that other navigation apps can “simulate” when driving in tunnels and loosing GPS coverage? They just continue on the same road in the same speed.
Would this be possible in waze?
This is on our “big” list of feature requests and bugs. Waze knows about it but implementation is probably lower on the priority list.
Tapatalk made me do it.
Same thing in Boston–compounded by the facts that the tunnels branch & merge underground (so routes traverse multiple segments before emerging), and traffic develops within the tunnels that may not be evident if you only see entrance & exit speeds.
IMO the only effective way to handle this kind of situation is to switch to a manual mode, where it tells/shows you what your next turn is, and you have to click a “next” button to proceed to the next step in navigation. (This is almost exactly how at least one other map app works, when used on a handset without GPS.)
Surely the traffic in a tunnel could be calculated.
Distance / time…simple.
Example:
Tunnel is 500 metres long.
GPS is lost on entrance and reestablished upon exit.
It takes 10 minutes to get through the tunnel.
500 metres ÷ 60 seconds = 8.33 m/s
or 18.6 mph or 30 kph
It can’t be that difficult to implement that, its basic arithmetic.
Sent from my GT-I9100 using Tapatalk 2
When the tunnels branch & merge underground, you can’t just calculate the average speed based on entrance & exit time, because the vehicle traverses multiple segments–some of which may be flowing freely, and some of which may be at a near-standstill for a quarter mile. It would take multiple vehicles, entering and exiting at each of several points, before you would have enough data to even start calculating average speeds for any of these segments.
Consider a simple network in which two tunnels (A and B) meet underground, travel together for a mile, then diverge before exiting (C and D). Calculating the average speeds of each segment would require a minimum of four unique trips (A->C, A->D, B->C, B->D) in order to determine the average speeds for A, B, C and D (where the average speed for E is the same constant in all four equations). It only gets more complicated–very quickly–from there, as the number of possible entrances & exits for this tunnel network increases.
I’ve been thinking about this over the past few days. Without GPS, it will still require special handling to deliver turn-by-turn instructions to a Wazer in a network of tunnels. But when it comes to routing, I think a feature currently under development could make a big difference: the “intersection object”.
Consider a network of tunnels, with multiple entrances and exits. As I explained above, figuring out the speed of each individual segment within the network is a significant mathematical task, involving a lot of data. But choosing the fastest route does not require knowing the average speed of each individual segment in the tunnel network for a given time of day; it only requires knowing the average aggregate speed of each possible trip through the network.
In other words, we define an intersection object that encompasses all the tunnel entrances & exits for a particular tunnel network. It could keep track of which entrances can lead to which exits, but more importantly, it would accumulate real-world statistics on average transit times for each (entrance,exit) pair, which the routing engine could use to find the best route (and detect traffic!) despite the unavailability of speed data for individual underground segments.
The map would still know which segments are connected to which, and what their names are, so we can still generate turn-by-turn instructions for the driver–presumably to page through manually while underground.
And if the driver doesn’t exit within the expected timeframe, generate a traffic jam when he does exit at the calculated average speed.
If one exit in a tunnel is backed up, you can be pretty sure that the main tunnel will be too. Even if not, it’s still better to assume an average speed for A>B>C as a whole, even if A>B may be OK. When a Wazer does A>B>D that can be calculated too and the resulting segment B>C can be left with the traffic report, A>B being cleared.
But yes this will involve some clever mathematics on the servers part.
Sent from my GT-I9100 using Tapatalk 2
The point being, the mathematics of deducing speeds for various “hidden” segments is not strictly necessary. It’s true that knowing that level of information could help Waze anticipate how severely other routes through the network would be affected by a slow-down along one route–but in order to determine that information, at least one Wazer has to take each of those routes anyway, which means we already have an idea of the aggregate times for each of those routes.
Over time, as data is collected, correlating a slow-down in one route to slow-downs along other routes could become a second-order, predictive task–so when there is an accident or backup in one part of the network, at least Waze could make an educated guess as to which other routes are likely to be affected–perhaps even to what degree.