[Update] Partial restrictions (time and vehicle type)

Moderator: Unholy

Re: [Update] Partial restrictions (time and vehicle type)

Postby sketch » Sun Aug 03, 2014 2:39 am

kentsmith9 wrote: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?

That is correct. The merger process compares your GPS trace directly to the segments on the map, with no regard for the route Waze gave you or the segments Waze snapped you to.

GPS resolution is generally good enough to show roughly which lane you were in. Yes, there will be occasional GPS errors and drift, but in general (at least with my phone in my car) it's pretty precise.

Look at your drives in the Drives tab if you wanna check it out. Turn the roads layer off and follow the green line along the satellite imagery. It may look a little off or jagged around turns but that's only because Waze only takes note of your location once per second. Also – the trace turns red when merger was unable to find a road or possible connection for whatever it is you actually did.
ALL US EDITORS READ: New USA road type guidance
new orleans based • detroit enthusiast • usa country manager
2013 ford focus titanium hatchback 5mt • performance blue
Image Image
sketch
Waze Global Champs
Waze Global Champs
 
Posts: 5662
Joined: Sat Aug 08, 2009 6:13 pm
Location: New Orleans, LA
Has thanked: 1227 times
Been thanked: 1679 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby qwaletee » Sun Aug 03, 2014 9:27 pm

kentsmith9 wrote:
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.


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.
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues
qwaletee
US Waze Champs
US Waze Champs
 
Posts: 2791
Joined: Wed Feb 13, 2013 1:42 am
Location: NYC Metro - Active throughout NE^2 (Northeast & New England)
Has thanked: 223 times
Been thanked: 1034 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby kentsmith9 » Mon Aug 04, 2014 3:52 am

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: 4986
Joined: Mon Apr 23, 2012 3:33 pm
Location: SF/SJ Bay Area of Northern California
Has thanked: 1247 times
Been thanked: 1473 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby qwaletee » Mon Aug 04, 2014 3:15 pm

Kent,

Got it. I imagine there are other places where we need to make exception, too.
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues
qwaletee
US Waze Champs
US Waze Champs
 
Posts: 2791
Joined: Wed Feb 13, 2013 1:42 am
Location: NYC Metro - Active throughout NE^2 (Northeast & New England)
Has thanked: 223 times
Been thanked: 1034 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby khaytsus » Thu Aug 28, 2014 10:55 am

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!
USA Country Manager
Central Kentucky Area Manager
AT&T LG G2 (AOKP 4.4.4)
Nexus 7 2012 (AOKP 4.4.4)
Samsung Galaxy Note (i717 AT&T; AOKP 4.4.4)
Image
khaytsus
 
Posts: 863
Joined: Tue Nov 03, 2009 10:43 pm
Location: Lexington, KY
Has thanked: 43 times
Been thanked: 84 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby CBenson » Thu Aug 28, 2014 1:38 pm

khaytsus wrote:but if he starts his route at 7:59 and would arrive at the TBR location at 8:10 what is the behavior?

My experience is that waze will route through a restricted turn in this circumstance.

There is useful turn is restricted until 6:30 PM that waze likes to use on my evening commute. If start my route before 6:30 PM waze will route me through the turn if I am predicted to make the turn after 6:30 PM.
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.3.0.1
CBenson
Waze Global Champs
Waze Global Champs
 
Posts: 10071
Joined: Wed Nov 03, 2010 9:13 pm
Location: Crownsville, MD, US
Has thanked: 1004 times
Been thanked: 2231 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby sketch » Thu Aug 28, 2014 2:54 pm

khaytsus wrote: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!

This is not the case. It has been confirmed by staff and in testing that TBRs are judged not by the time the route is started, but by the time you are expected to get to that particular TBR.

The benefits are obvious; the drawback is that, in threshold cases, you may be routed through one if it expected you to get to the turn at 8:01 but you actually got there at 7:59. That's not even really a drawback, though, compared to the other case (which would hypothetically route you through a restriction if your route started before it began).
ALL US EDITORS READ: New USA road type guidance
new orleans based • detroit enthusiast • usa country manager
2013 ford focus titanium hatchback 5mt • performance blue
Image Image
sketch
Waze Global Champs
Waze Global Champs
 
Posts: 5662
Joined: Sat Aug 08, 2009 6:13 pm
Location: New Orleans, LA
Has thanked: 1227 times
Been thanked: 1679 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby qwaletee » Fri Aug 29, 2014 4:45 am

I am finally following up on the HOV/HOT guidance discussion above. I have produced a test revision page that is close the version I proposed, incorporating the suggestions of I believe sketch, kent, and CBenson, with some revisions of my own.

Please take a look and let me know what you think. I suspect the wording can be simplified/bulletized in some cases, and other formatting changes. But please let's start with whether it is sagacious, before we tinker with the presentation.

https://wiki.waze.com/wiki/Carpool,_HOV ... s/Revision

Note that the discussion of HOV/HOT is probably a diversion for this thread, so we may want to move the posts related to it into a dedicated one.
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues
qwaletee
US Waze Champs
US Waze Champs
 
Posts: 2791
Joined: Wed Feb 13, 2013 1:42 am
Location: NYC Metro - Active throughout NE^2 (Northeast & New England)
Has thanked: 223 times
Been thanked: 1034 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby CBenson » Fri Aug 29, 2014 10:28 am

I'm not understanding the guidance.

For 1b I continue to think the guidance should be to use the road type appropriate to the road and mark all entrance segments as restricted to all but the allowed HOV vehicles. I don't see any rush to change from parking lot roads to HOV restrictions, but the guidance should be to use HOV restrictions as that is clearly where waze is going. There are disadvantages with parking lot roads. They prevent routing all the time, so they are now inappropriate for time-restricted HOV lanes (e.g. HOV from 7:00 to 9:30 AM). Such lanes should be time/vehicle restricted so that waze will route on them the rest of the time. Parking lot roads are also much more likely to be used a routing destination than freeway segments. Thus, if you have a parking lot HOV road running up the middle of a freeway and there is a destination pin nearer to the freeway than adjacent parking lot roads, waze may route to HOV lanes. This is less likely to occur if the HOV lanes are also freeway type.

For 2a, same thing, I think HOV restrictions should be used rather than PLR.

For 2b I do not understand the note:
Drivers who are not permitted to use the lanes may be routed by Waze via them, but it is up to the driver to obey traffic laws, and Waze will successfully re-route around them when the driver does not enter the special lane.

If the lanes are restricted to HOV only waze will not route onto them. They may be used if waze recalculates a route starting on them either because the wazer is driving on them or because of GPS error. But one should never get a turn instruction to take the HOV lanes.

Some HOV lanes go back and forth between being less than and more than 10-15m from the regular lanes. Currently I would read the guidance to mean such roads should not be mapped as they are not almost always over 10-15m away from the standard lanes. But you still get map problems and sometimes recalculation issues (sometimes to the opposite direction lanes) even if you only are separated significantly from the regular lanes for a relatively short distance. I think the "almont always" should go with the minimal separation so that lanes that vary between minimal and significant are treated as significant separation.

Under future support the following are still listed:
The ability to change the direction of the car pool lane automatically based on time of day and day of week. This is also necessary for other roads
The ability to set the minimum passenger count to zero (meaning the road is open to all drivers) based on time of day and day of week

These are currently supported in the editor.
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.3.0.1
CBenson
Waze Global Champs
Waze Global Champs
 
Posts: 10071
Joined: Wed Nov 03, 2010 9:13 pm
Location: Crownsville, MD, US
Has thanked: 1004 times
Been thanked: 2231 times

Re: [Update] Partial restrictions (time and vehicle type)

Postby qwaletee » Fri Aug 29, 2014 7:17 pm

CBenson,

I believe we covered most of this earlier in the earlier discussion, but I have no problem opening it up again. The logic behind the overall solution is in bullet points below, but I'd like to address what I think are the main themes of your questions first.

You are bothered about the choice of PLR versus HOV restrictions checkboxes. Long-term, I agree. For now, since I don't have a crystal ball telling me when Waze will be ready to release bug-free HOV preferences in the app nor how long it will take for the new version to become prevalent, I'm continuing to not rely on them. It's "soon" syndrome, right?

If my POV on "the future" is incorrect, then yes, I need to rework this. If my POV is correct, however, would you still have those objections?

On the amount of separation and varying separation, I see your point. Needs some additional work in this area. I was thinking about situations where there are long stretches of crowding, where the GPS inaccuracy could be a real issue.

Future direction - definitely outdated, I didn't touch the rest of the article, and I should. I'll try to get to that over the weekend.

------------

Summary of the logic leading to the current decision matrix (for those who do not want to re-read the whole thread):

* We have an imperfect system, we have no way of having true restrictions today, or of consistently either allowing the route or disallowing them.

* Where there is a special advantage to the routes (not just a dedicated lane, but a bypass route) we want to allow Waze to take advantage of them. Therefore they need to be completely restriction-free, and we rely on drivers to recognize that they may need to bypass it. Expect URs, but nothing we can do about that. By definition these will be limited access roadways, so they will always be Freeway. This is case (2b).

* Where there is no special advantage other than a more lightly traveled lane, we want Waze to ignore the dedicated lane for route proposals, but recognize it if taken anyway, to avoid MPs and to record corrected data where possible. This is case (1b).

* The commonality of the "b" cases above is that Waze can differentiate lanes. For the "a" cases, it will probably not be able to differentiate, so for both cases, we don't want to map. Where there is no difference between the restricted/unrestricted lanes, there's really no case for mapping (2a), but there may be some circumstances where we want to map (2b) because otherwise we could be closing off a real routing option.

* In some areas, this guidance will create routing problems for many editors. Because of this, always check local guidance. An example is the San Francisco area, where the combination of HOt (toll lanes) and unavoidable bridge tolls would lead to questionable routing under the proposal.
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues
qwaletee
US Waze Champs
US Waze Champs
 
Posts: 2791
Joined: Wed Feb 13, 2013 1:42 am
Location: NYC Metro - Active throughout NE^2 (Northeast & New England)
Has thanked: 223 times
Been thanked: 1034 times

PreviousNext

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: No registered users