One way to solve this could be to use the accelerometer in the phone. So when you lose GPS waze switch over checking the accelrometer and use that info for increasing or decreasing the speed the car had when gps was lost.

The lost gps in tunnels also takes away the traffic in tunnels so if there is a traffic jam in the tunnel you will not be warned by other wazers. but if waze caluculate an approx. position and also "feels" if the car stops you will get a warning if there is a traffic jam in the tunnel.

urnekleivi wrote:What about tunnel simulator. When will tunnel simulator get availablle for use??? A bit annoying entering a tunnel not knowing what to do when i exit, should be easy using average speed thru the tunnel... =)

Figuring out the average speed through the tunnel is not straightforward, under the current segment-based model, when there is no GPS data for those segments. It could be extrapolated from the gap in GPS data--but then you have to make sure you aren't polluting valid speed data due to a malfunctioning GPS unit. You would need to be able to designate segments as tunnel segments in the map database, then implement a whole different way of navigating while on them.

My suggestion was to provide manual turn-by-turn instructions, like "some public nav tools" offer when GPS is not available: hit the "forward" arrow as you make each turn, and it shows you the next instruction. The client might even derive speed data from this mechanism. But this would be a non-trivial project.

I've been using Waze for about a week now. Great. Except the tunnels! And in Boston, that's hard to avoid.

Thinking about the problem, I agree with the suggestion of marking segments as tunnels (or ferries or bridges). Basically you'd be saying "you can't get out of this segment once you're in it, so don't try to reroute me unless you detect I'm no longer in this segment." You could supplement that with the knowledge of the route before entering the tunnel. So if it knows you entered the tunnel, and the current GPS signal (like when you're getting to the end) says that you could still be in the tunnel, then assume that you are still in the tunnel and did not magically appear on surface roads above the tunnel. Something like that.

It's easy to think of the algorithm. I'll leave the actual implementation as an exercise for the waze engineers!

+1

And then wait for good GPS signal before reactivating rerouting code after exiting a tunnel segment(s)

Nothing like having poor gps lock coming out of the tunnel, and being told you are on surface streets two blocks away.

+1

My idea was more like editing tunnels as "tunnel-segment" or "tunnel-road" in the editing tools. making the start and end of the tunnel Locked and then forcing Waze to calculate approximate position untill gps signals are back up. (could be convenient not only entering tunnels but also when losing gps signals.) waze keep driving using average speed or speed when gps was lost and stays on the navigation, it's assuming that you follow navigation /stay on the same road.

the average speed would then be calculated as one speed on the tunnel-segment, time betwen losing and geting gps signals back, the average would still be better than nothing.

The editing tool should get tools to differentiate betwen normal road, tunnels and ferries now, and then deal with the programing of waze later.... (it being turn by turn, approximate position or other solution.)
=)
joust an idea from a country with lots of tunnels