Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!

Post Reply

[Update] Partial restrictions (time and vehicle type)

Post by
Please use this page to discuss the Wiki topic Partial restrictions

The most recent discussion about this page was in the dedicated topic regarding a name change: viewtopic.php?f=276&t=93511&p=785008#p785008

POSTER_ID:14073768

1

Send a message

Post by bz2012
I note a conflict between
short term construction (long term closures should use disconnected roads, though time restrictions may be used to synchronize the start or end of the closure period)
and
Disconnect road segments - Road segments should only be physically disconnected if the road is no longer intended to connect or is being permanently removed. While In the past, this method was used for longer term construction projects, the Road Closure feature should now be used.
Revision appears to be needed to resolve the conflict.

It appears to me that the first paragraph, which is very close to the beginning of the wiki, should be revised. I suggest it be revised to read simply
short term construction (see Disconnect road segments below, for permanent closure situations)
bz2012
Map Raider
Map Raider
Posts: 1621
Has thanked: 1968 times
Been thanked: 304 times
Send a message

Post by CBenson
kentsmith9 wrote:we have a similar HOT lane . . . . The lane is essentially unavailable to drivers, unless you start navigation when IN the lane. . . .

Of course it is mostly moot until we get carpool or HOT status enabled in the client.
We are not expecting to get HOT support distinct from HOV support are we? In other words we already have all the support we expect to get for toll part of the restriction don't we? Why is the lane not available to the toll users?
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
Yes, those are issues. And they cause many URs as noted here for the HOT lanes that are mapped on the Washington Beltway (except for the PLR penalty not being high enough as you have to use the avoid toll penalty to avoid them). But for those that want to pay to avoid the traffic, why wouldn't we map them?
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
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.
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
kentsmith9 wrote: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.
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.
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
I'm all for that. I agree that in many jurisdictions there are avoidable toll roads and unavoidable toll roads.

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. Even if waze can find a non-toll route, it will still present a faster tolled route as an alternative. There can be issues if there are multiple toll choices and the map is not edited to mark only the segment with the toll both as toll. It seems in this instance, where you have avoid toll roads selected, but there are only toll choices, waze picks the one with the fewest toll segment. This seems to me to indicate that with avoid toll routes currently selected for a typically communing length route, waze would at least give you an option of a route that routes over the unavoidable toll bridges but would still avoids the avoidable toll roads.

So given we don't have two toll options in the client like you propose, the question becomes how should we map HOT lanes. Should we map them as toll roads so that those that want to avoid the traffic by using them can see them as options and see how much time they may save by using them. Or should we map HOT lanes only as HOV lanes so those that don't want to pay for them will not be routed over them even when they don't have avoid toll roads enabled. At this point I think we should map to make the routing work for users that can either say yes or no to the the question - do you want to route over toll roads? Then waze can add features to cater to those that need more options.
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
Ahh, well you would have more experience with this issue. The problem would seem to be one of tuning the cutoffs, which could be done more easily with the second toll option that you propose. For my simple test I routed from Orinda to San Francisco so the land routes were a bit longer.
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
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.
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
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.
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
qwaletee wrote:* We have an imperfect system, we have no way of having true restrictions today, or of consistently either allowing the route or disallowing them.
I'm not sure I understand this. We map HOV lanes and disallow routing on them currently. We used to use PLR to dissallow them. Now we can restrict them to only HOV vehicles which also disallow them.
qwaletee wrote:* 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).
Case (2b) states:
Set segment restrictions for HOV "vehicle type" if applicable.
This would seem to me to always be applicable as we are talking about carpool, HOV and transit lanes. This would not then be completely restriction-free.
qwaletee wrote:* 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).
Again we would get that result by either restricting the roads to only HOV vehicles or making them parking lot roads. I don't see why the guidance going forward should not be to restrict them to only HOV vehicles.
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902