[SUPPORT] Traffic Avoidance Failure

[foxitrot]

The same location, light red traffic jam 29 km/h on D1 freeway between Senec and mid Bratislava. I've first requested a route (at around 8:35 UTC) with client exactly over the jam length, equaling this one http://world.waze.com/livemap/?zoom=7&l ... g=60197491 My ETA was 16 min./21 km, although the traffic jam was 29 km over its whole length. I've taken a few screenshots along the jam, but did not look for wazers.

At around 8:42 UTC I've taken a screenshot from LiveMap - the jam was already a bit shorter (18.5 km) and faster and (at least on one small part of it) was rated "Heavy traffic, From Velky Biel to Ivanka pri Dunaji on D1. Avg. Speed: 32 km/h, Duration: 23 minutes, 5 minutes ago" -> it is not pssible to make 18 or even 21 km in 16 or less minutes, if such traffic is en toute. To document the jam area, I've requested a route along it http://world.waze.com/livemap/?zoom=7&l ... g=60239014 with resulting ETA 13 min/18.5 km.

As the jam seemed to be getting shorter again, I've requested one more route over the shortened length at 08:45 UTC (8 min/10 km) http://world.waze.com/livemap/?zoom=7&l ... g=60239014 while a reddish rectangle on my screenshot, pointing to the first part of my route, says "Heavy traffic, From Chorvatsky Grob to Ivanka pri Dunaji on D1. Avg. Speed: 20 km/h, Duration: 13 minutes, 8 minutes ago" - Again an impossible combination of ETA and jam speed and length, at one and the same screenshot.

Later I was taking more and more screenshots and routes, but still with impossibly small ETA. I'm convinced to confirm that txe fixes are either not live yet, or did not apply to this problem The ETA seemed to take just historical traffic into account. I've not calculated my expected ETA times, but with the jam speeds I'd assume 2x - 3x more.

Even now at 09:30 UTC, as the freeway jam is only "Moderate traffic, On D1 in Bratislava, Avg. Speed 40 km/h, Duration 8 minutes, 3 minutes ago" I'm getting a route http://world.waze.com/livemap/?zoom=7&l ... g=58968331 with just 4 min. ETA.

All these examples were along a lot of segments (I'm noting this, as I've discovered a couple of days ago, that if one jam happens on one long, solid freeway segment, the resulting ETA along it was always 0 minutes, regardless of the jam length and speed).

[jondrush]

I've noticed that since you've made the changes, Waze is much quicker to show a traffic problem on the phone. Sometimes a nonsensical display. I live in a rural area and when I drove to work today, many of the roads around me were reporting jams with a speed of zero. I wasn't quick enough to grab a screen. Last night I turned onto a short road, and just after I turned, the whole segment showed up with a speed or 25. I was the only car visible on the road, so I assume I caused the jam report.

[gettingthere]

Here is what I have noticed in regards to automated traffic jams after the fix was applied:

* Maybe Waze is handling traffic better?? I have seen several messages regarding traffic building, not yet seen it flipping back and forth between traffic building, traffic freed up.
* Waze has re-routed me twice in two days to save time. 'We found a faster route, time saved 2 minutes'. Although I question whether it is worth changing the route to save only 2 minutes...
* In one case after Waze reporting a faster route, saving two minutes - Waze did not recalculate the route right away. It took maybe 30 - 60 seconds to figure out that the route had to be recalculated.
* I am still seeing issues with the route preview screen when setting a route or looking at alternative routes. Jams that show on the map but not on the preview screen, different color's for the jams - eg. yellow on the map but red on the preview, etc.
* It also appears that the Reports functionality is not taking into account all of the jams. This morning there was a jam on my route. The reports screen filtered to on-route was not showing the jam.

So seems to be improved, but still some issues. It is really difficult to trust that it is working properly when there data is not being consistently presented throughout the Waze application.

[guri211]

Today evening - still no traffic avoidance There were at least 2 options how to avoid this jam. Unfortunatelly the ETA is still wrong, therefore Waze is not trying to use the alternatives.

http://dl.dropbox.com/u/10259654/SC20120315-195009.png
http://dl.dropbox.com/u/10259654/SC20120315-195311.png
http://dl.dropbox.com/u/10259654/SC20120315-195930.png
http://dl.dropbox.com/u/10259654/SC20120315-200149.png

[foxitrot]

Today the usual morning' traffic jam in the city (Bratislava, Slovakia). There was a 14 km/h red traffic on a D1 freeway through the city. Initially I've got an 13 min/8.8 km ETA for a route along the jam, which still seemed too optimistic for me. At further look I've noticed that the client tried to route me through all possible side streets to drive around a part of the jam - even less possible ETA for the given route and the time of day.

So I've requested also the alternate routes - OMG the route directly through the traffic jam was recommended as an alternative one, with way much better ETA!! Did one routing subprocess calculate a list of optimal routes and another one has attached wrong ETA's to the list?

Scr000720-22_.jpg (74.06 KiB) Viewed 687 times

Hey, devs, come on! The chaos is getting worse

[islupepa]

Did one routing subprocess calculate a list of optimal routes and another one has attached wrong ETA's to the list?

This is my experience too. Waze tries to avoid traffic jams if it's possible, but if it's not, it doesn't consider the traffic jam at all (higher ETA).

[osbumlets]

Not so sadly, I'm happy to say we found the issue and deployed a fix.

The fix should solve two of the three problems mentioned here:
1. ETA is not realistic / changes while you drive
2. Traffic avoidance is not working (and takes you smack to traffic)

Sorry no, not fixed in the least.
I-85 N in Gastonia, NC (west of Charlotte, NC) had an accident that shut down the interstate at exit 23. People have not moved at that exit for the last 40 minutes. Traffic is backed up for 15 miles. Waze still routes you smack into it although the road speeds known and shown are 0, 2, and 4 MPH. Gives an ETA that is ***3.75 HOURS*** faster than what it should be calculating.

Here is the math: http://www.wolframalpha.com/input/?i=HO ... S+AT+4+MPH

Before anybody says it, yes there are alternatives that are known and mapped out. In morning rush, they could be A LOT slower, but that is still faster than a closed highway 100% of the time. If anybody was going to say that it's because of the extreme slow-downs that are throwing off Waze, I can also give more examples during my normal afternoon commute that is always 20 minutes longer but constantly says I should be home 5 minutes from now. "1. ETA is not realistic / changes while you drive"

Attached is a screenshot of all of the victims of traffic avoidance failure. They were all told that they'd be at work or school 45 minutes ago if they followed Waze's instructions.

We've all taken a lot of time to describe this problem to you. Part of the core functionality of Waze is traffic avoidance. It's in ALL of your videos and descriptions that advertise waze. I really hope you can give it more attention and fix this. Thank you.

[CBenson]

Sorry no, not fixed in the least.

I agree with everything you said except the above part. What you describe seems to be a huge problem for waze. But, I think there may multiple issues with routing around traffic and waze may well have fixed some of them. My thoughts are that waze has never handled road closures well. I've never been sure that waze properly handles road speeds of 0, 2 and 4 mph. I agree that this a huge problem. On major urban highways where there are a significant number of wazers, I believe that waze handles road closures better. I think this is because there are usually slower segments but with speeds greater than 4 mph approaching the segments with standstill traffic. These slow but moving segments seem to trigger better alternative routes than the standstill traffic. I have no good evidence for feeling that waze works this way, it is just my gut hunch from using it. Again I do think the innability to consistently route arround accidents that essentially close a highway is a huge problem for waze.

As an aside, it also seems to me that waze does not take into account a road that has no traffic at all. Thus, if a road is closed for some reason but there are good detours in place waze does not detect the closure. No slow down, no rerouting. Waze thus continues to route over the closed road.

[gettingthere]

Another example, Waze's core functionality is STILL NOT WORKING CORRECTLY. I cannot no longer trust that Waze is taking me the fastest way. The product is broken.

I still believe that Waze is not syncing route and traffic data in a timely manner between their routing servers. As part of the infrastructure improvements, Waze had introduced redundant routing servers.

This is on the US/Canada infrastructure. This morning March 21, 2012 - San Diego, CA. Times are in the screen shots, Pacific Time.

I am on route to Work with an ETA of 7:45am. As you can see there is traffic ahead. There are plenty of Wazers here and the traffic jam data is current.

1.jpg (27.63 KiB) Viewed 649 times

I get a pop-up stating that traffic is building, 5 minute delay, new ETA 7:52am. Wow, it seems that Waze is working and letting me know that traffic is building (which it is) and I will be arriving later to work.

2.jpg (28.75 KiB) Viewed 649 times

So I think, hmm - there are some great options with other freeways that I can get to easily that may be faster. Is Waze properly accounting for this traffic and is this still the fastest route? Initially instead of clicking on alternative routes, I end my current route and set a new route to work. Uh-oh, why does the ETA show 7:46am when a moment ago I was informed that traffic was building and the ETA is 7:52am. This is the exact same route.

3.jpg (21.68 KiB) Viewed 649 times

OK. So now I really want to know if this is still the fastest way so I click on Alternative Routes. The route preview graphics don't look to be correct, but ok, Waze says that that is not fixed yet - so I am ignoring the graphic. But what do you know, I am on route option 1. ETA is now showing at 7:47am (current time 7:30am + 17 minutes = 7:47am). Again, why isn't this showing 7:52am??

4.jpg (28.37 KiB) Viewed 649 times

So I still don't know if option 1 is the fastest route or maybe I should have detoured to option 2 which is showing ETA of 7:46am (current time 7:30am + 16 minutes = 7:46am). But really, are any of these ETA's correct? So I continue to drive on my current route through the traffic. Once I get through the traffic, what is the updated ETA?? 7:52am. So the initial 5 minute delay, ETA update was correct - but when setting a new route, looking at alternative routes, etc - the ETA goes back to the previous ETA and is not factoring in the current traffic.

5.jpg (25.67 KiB) Viewed 649 times

So back to my initial thought on this issue. Is the Waze application getting different ETA's since it's communicating with more than one routing server? One/some of the routing server(s) have the up to date traffic jam data and ETA. But one/some of the other routing server(s) have out of date data and are providing different ETA's.

Until this is resolved, I have ZERO confidence that one of the key functions of Waze (traffic avoidance) is working. This needs to be addressed. It is not fixed.

[CBenson]

When krankyd said:

If you can post examples - like the ones you posted here before - of cases where waze's ETA is still off, or fails to avoid traffic, please let us know.

does that mean posting the examples is sufficient to "let them know," or does someone need to tell them directly that there are more examples where the ETA is still off and fails to avoid traffic.