Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!
Post by kentsmith9
Your examples that is not working is interesting to hear. In California along I-680 S between Sunol and Milpitas we have a similar HOT lane that I get to ride in every day. The original setup is slightly different from the guidance (mainly because my route was working when others wanted to use a different method). With over a year with no problems maybe we should look at it again and update the guidance to match it. The lane is essentially unavailable to drivers, unless you start navigation when IN the lane. That is due to the phone GPS resolution unable to snap into the adjacent lane if you started outside of it.

Of course it is mostly moot until we get carpool or HOT status enabled in the client.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message

Post by kentsmith9
I agree with qwaletee's overall proposal with one exception on mapping them or not. At some point in the past I was told that the snap to tracking is for visual reference, but the routing server is tracking the actual location of the vehicle relative to speed information. Therefore when a driver is in the HOT/HOV lane, even if Waze shows them in the std. freeway lane, the fast moving driver is not altering the freeway speed data. Have we confirmed or disproved that information?
CBenson wrote:But HOT lanes should not be mapped as PLR. You want those who are willing to pay the toll to be able to route over them. There is no reason not have them set to tolled freeway type now so that they can be used for routing.

I don't see any reason to map HOV lanes as PLR at this point. Where appropriate to map them, just map them with the appropriate HOV restriction. However, no-one will be routed over a segment with a HOV restriction. So there is really no reason to spend much effort at this point to change HOV lanes previously mapped as PLRs to freeway (or highway) type with HOV restrictions.
Without additional client features I think this is still a problem to open it up as described. In the SF Bay Area we have 7 toll bridges which provide virtually the only access to those locations on the other side of the water, so everyone pays the toll. In the stretches of freeways leading to the bridges we have HOT lanes that drivers are not willing to pay due to the limited benefit. So a user who lives in the bay area will leave the Toll route option on all the time to enable bridge crossing, but then would be continuously routed in HOT lanes.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message

Post by kentsmith9
CBenson wrote:I agree that is a problem and you may have do something different in the SF Bay Area. But that is a permanent issue. We can't account for both drivers that want to use some toll roads and drivers that want to use all the toll roads. This will remain an issue even after the HOV indication is enabled in the client.
Maybe the SF area is the only one with this condition as you said, so may not be worth investing in a fix for it, but my idea was likely to be universal to any situation. The client would have two toll options. 1) Avoid all tolls (as it works today), and 2) Avoid tolls unless it reduces travel time by 50% (or some number) (with a minimum of 15 min required savings or something).

For SF that would automatically keep bridges and avoid HOT. For other areas with Toll roads people normally avoid, it would add them into the options if there was an accident on the free road and the toll road was a major savings.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message

Post by kentsmith9
CBenson wrote:However even if I have avoid toll routes selected, waze will route through toll segments in some instances. For long routes over 100 miles or so I get an error if the only non-toll route is too circuitous on low road types. But for shorter commuting type trip lengths, waze simply gives me a toll route even if I have avoid tolls selected and there is not a reasonable alternative.
I seem to have a different experience just now in a test. Near the entrance of the San Mateo bridge I routed across to the coastline. With avoid toll, the three routes were by land only and took 60 minutes plus. When I allowed toll routes, two of the three routes were across the bridge and the direct route was 35 minutes. The other two had other roads to get to the coast that ended up taking as long as 60 minutes.

So if I had avoid tolls during my commute to work, it would not give me a bridge if it saved 25 minutes of my 60 minute route. That is a fail in my book.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message

Post by kentsmith9
qwaletee wrote:That's a fail in that the routing engine has a very limited toll avoidance system. It is not aware of relative costs of tolls, number of tolls, and balance of toll size versus detour. In my limited testing, it seems that avoid tolls is applied at just after the pruning process. If it fails to find a route at that point, it will drop the toll check, and go back to using any route that was not pruned, even a tolled one. But if the only untolled route uses local streets, you won't get that route.

If we had a way of indicating relative amounts of tolls across the route, and there was some sort of slider for detour:toll instead of just a checkbox, then you might be able to get what you want. Until then, in many cases, you can end up with what you got. Fail? Yes, for real life. But that;s a system limitation, not a bug, adn we have all sorts of system limitations that are frustrating when routing using Waze.
My only point is that the current method we are using in the SF Bay area for HOT lanes is working well enough given our limited options and complex toll combinations in the same trip. Therefore we can change the Wiki guidance for the rest of the country, but we will likely be different in northern CA to keep it working here.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message

Post by kentsmith9
That is the first time I have seen staff report on roads. I assume the reporter was a Waze or Google employee and contacted Ohad-Ron directly.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message

Post by kentsmith9
I sent a message to him asking him to reply to this thread if possible to help us understand why he is making these changes against our understanding of the current Waze abilities.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message

Post by khaytsus
Would it be possible to clarify in the wiki precisely what happens when starting a route that goes through a TBR prior to the TBR starting?

Example.. TBR from 6:30 to 8:00 am and the users route goes through the TBR. If he starts his commute at 8:00, it would certainly route through the TBR as it's not restricted at that time, but if he starts his route at 7:59 and would arrive at the TBR location at 8:10 what is the behavior?

My expectation is the routing engine gives him a route that routes around the TBR and unless for some reason he receives new routing information (deviates from path, traffic, etc) he'll be routed around the TBR, even though he will be driving through it after 8:00am.

Thanks!
khaytsus
Posts: 863
Has thanked: 29 times
Been thanked: 68 times
Send a message
USA Country Manager
Central Kentucky Area Manager
AT&T LG G2 (AOKP 4.4.4)
Nexus 7 2013 (Cm 13.1)
https://dl.dropboxusercontent.com/u/334 ... ze-500.gif


Post by KuniaKid
eaglejm7 wrote:It seems that time based restrictions on a private road do not work. My son's school has a road that is private (non-school days it is blocked by gates at both ends), but during school days it is completely closed for an hour in the morning and 40 minutes in the afternoon. In the afternoon, there is a further 2 hours of one way for extended carpool. Since it is gated, it is marked as private. When navigating to a point on that street, the time based direction restrictions appear to be ignored as it keeps routing me the wrong way on the street. When I approach from the other direction (as I always do), it allows routing along the street that way as well.

Permalink?
KuniaKid
State Manager
State Manager
Posts: 497
Has thanked: 277 times
Been thanked: 118 times
Send a message