Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!
The place to get information and ask questions about everything to do with properly and successfully editing the Waze Map.

Use this forum for all general editing questions, and the sub-forums for specific types of Waze Map Editor features.

Post Reply

Traffic Locks

Post by
SuperDave1426 wrote:
sketch wrote:Traffic locks are something we're testing in the beta now. Toolbox should probably disable them for the production editor ;)
That still doesn't tell me what the difference is between a Lx Lock and a Lx Traffic Lock. :-)
Traffic locks are automatic locks generated based on the amount of traffic that uses a given segment. We're still working out the details in the US—for instance, no segment should be automatically locked at L6 under any circumstances. We're also gunning for immunity for AMs within their managed area. We don't intend to sign off on it unless that is achieved one way or another.
Goodolsen wrote:JNF is updated already to v 0.0.8.2
1000th post! Very nice :)

POSTER_ID:5415

1

Send a message

Post by AlanOfTheBerg
sketch wrote:Traffic locks are automatic locks generated based on the amount of traffic that uses a given segment. We're still working out the details in the US—for instance, no segment should be automatically locked at L6 under any circumstances. We're also gunning for immunity for AMs within their managed area. We don't intend to sign off on it unless that is achieved one way or another.
And the other Big Deal with traffic locks is that no one can set the lock lower than the traffic lock. That effectively kills the "unlock request" idea, and everything then becomes and "update request." If at least Area Managers can adjust anything in their area regardless of lock, that would help.
AlanOfTheBerg
EmeritusChamps
EmeritusChamps
Posts: 23627
Has thanked: 568 times
Been thanked: 3478 times
Send a message
Wiki Resources: Map Editing Manual | alanoftheberg@gmail.com
Oregon-based US Ex-Global Champ Editor | iPhone13Pro - VZ

Post by bgodette
davielde wrote:One additional question/scenario that may not be possible to answer right now:
When a segment is split due to a new junction, the two new segments that were created out of the original have IDs that differ from the original segment's ID. The former ID is simply gone, and the two segments have new sequential IDs, but the properties of the original segment such as Created Date and the manual lock rank are inherited from the original. Even though the average speed data drops to 0mph initially for the two segments, can it be assumed that "how many people have ever driven on a segment" would be one of the inherited properties? In that way, all of the factors that weigh into "Segment Rank" (the term as it appears in the standard editor) would therefore be preserved the next time the ~monthly process runs, and we wouldn't see a downgrade in the traffic lock/road rank/segment rank for just those two segments. It would seem silly to have a road traffic locked at 3 suddenly have two segments drop to 1 or 2 the next time the process runs just because someone added a new junction for a parking lot road, for example.
That's answerable. When you split a segment the original segment ID is included in the objects sent back to Features. Features copies all historical data to the two new segments and assigns them new positive IDs. Everything is inherited correctly.

The average speed data does not drop to 0, that's just a display bug caused by the changes not being propagated and forcing a Features refresh clears it.
bgodette
Waze Global Champs
Waze Global Champs
Posts: 3441
Has thanked: 27 times
Been thanked: 257 times
Send a message

Post by bgodette
kentsmith9 wrote:
bgodette wrote:That's answerable. When you split a segment the original segment ID is included in the objects sent back to Features. Features copies all historical data to the two new segments and assigns them new positive IDs. Everything is inherited correctly.

The average speed data does not drop to 0, that's just a display bug caused by the changes not being propagated and forcing a Features refresh clears it.
Does the system only track MPH / KPH so when the segment is split the two new shorter lengths does not affect the speed? Or does it track time to cross the segment so when you split it the time would not coorelate to the two smaller segments properly without taking a weighted average time based on percentage of total distance per new segment?
Speed is a synthetic based on segment length / transit time. What's stored is transit times and is partly why Waze told us there's issues with short segments, the other major reason being GPS update frequency. When you split new times are generated based on the two+ new segment lengths. This was not the case back with Cartouche where changing length/splitting/merging would corrupt that data.
bgodette
Waze Global Champs
Waze Global Champs
Posts: 3441
Has thanked: 27 times
Been thanked: 257 times
Send a message

Post by bgodette
kentsmith9 wrote:
bgodette wrote:What's stored is transit times
I didn't recognize if you answered the question if you know if they do anything to convert the transit time (e.g., 30 seconds) on a segment into some split of the time between the two new segments (e.g., each getting 15 seconds for two half-length segments)?
Yes, Features does the necessary math. That's why saves for splits and merges take so long compared to saves that don't contain such actions.
bgodette
Waze Global Champs
Waze Global Champs
Posts: 3441
Has thanked: 27 times
Been thanked: 257 times
Send a message

Post by bgodette
dbraughlr wrote:
bgodette wrote:That's why saves for splits and merges take so long compared to saves that don't contain such actions.
It sounds like it ought to do the math anytime the length of segment changes. It is very common to shorten or lengthen a segment even without a split or a merge. I realize that it doesn't have to be precise, but changes that are a substantial portion of a segment length are common.
It doesn't have to copy the data to two or more new segments, it's an update in-place.
bgodette
Waze Global Champs
Waze Global Champs
Posts: 3441
Has thanked: 27 times
Been thanked: 257 times
Send a message

Post by bz2012
Looking at the table on the following page:
https://wazeopedia.waze.com/wiki/USA/Ed ... Rank_table
I have a suggested format change, ordering by minimum rank, ascending:
https://cdn.discordapp.com/attachments/ ... nknown.png
https://cdn.discordapp.com/attachments/ ... nknown.png
Reorganizing that way seems to make the chart more useable to me.

Disregard the first column, my copy/paste sort seems to have scrambled that column for some reason. It needs to match the 2nd column. I was just trying to show an example of the whole table sorted by the rank numbers.
bz2012
Map Raider
Map Raider
Posts: 1621
Has thanked: 1968 times
Been thanked: 304 times
Send a message

Post by CBenson
fernandoanguita wrote:Most of damage, I think, is made by level 1 and level 2 editors, due to no initial filtering or forcing reading the wiki and forum participarion to start editting.
I don't know about this. I find plenty of problems caused by rank 4 and 5 editors. I'd prefer a review system rather than a lock system, that way experienced editors would be able to educate new editors. But the lock system is more or less all we've got at this point to protect the map.
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 davielde
karlcr9911 wrote:If they are, the AM areas must be left for the AM to manage freely or they're needs to be a lot more rank 5s promoted (even if they don't have the edit count but qualify based on editing knowledge) to assist with unlock requests.
There is a large experience gap between a new rank 3 AM with 10k edits and a more seasoned rank 3 with 99k edits. As a rank 4 who only recently crossed the threshold, I'm certain that there will be a lot of experience gained before 250k. I therefore disagree that an AM should be able to freely manage everything in the area. Editing knowledge is scrutinized to an extent during the review process to become an AM, but there is also the ability to make a number of corrections to an area without necessarily gaining the appreciation of *why* something should be corrected. It just means that they read the wiki. Or worse, they installed a script like Toolbox without reading the wiki, simply see an indicator, and become a mindless bot making it appear that they know what they are doing (not a criticism of Toolbox or any other script, just of such tools in the hands of editors who maybe don't know *why* a fix needs to occur).

Rank 4 and 5 locks can be an annoyance sometimes, but they also hold back less-experienced AMs (not to mention new editors) from making inadvertent mistakes to heavily traveled roads that would have the most impact on drivers and cause more URs. I have no business editing freeways right now, and I'm okay with that.

Auto locks and the current manual system also allow the champs or whoever else is handling unlock requests to briefly review why something is being unlocked or updated. Even experienced editors make mistakes or need to re-read the wiki at times or be reminded of something by another editor...

Having people earn higher ranks rather than simply being a 10k AM or being promoted to 5 based on quality work in a small area but not having the 250k edit count also provides an incentive to learn and gain experience. That could be lost if I were able to edit *everything* in my area.
davielde
Posts: 1219
Has thanked: 454 times
Been thanked: 735 times
Send a message
https://www.waze.com/wiki/images/6/69/W ... 00k_5c.png
CM: USA
SM: Michigan, Vermont
AM: Ann Arbor, MI & Thunder Bay, ON
WME Michigan

Post by davielde
How does time play a role in judging traffic volume? How often (if at all) would traffic locks be re-evaluated--monthly, yearly, etc? Average over time should be based on a long enough period to avoid seasonality. For example, volume for northern Michigan will be a lot larger in summer for most roads, which reflect vacation and tourism traffic. Winter volume may be high around ski areas but would not have nearly the same level as summer traffic coming from downstate or out of state. This type of variation should not influence lock rank.
davielde
Posts: 1219
Has thanked: 454 times
Been thanked: 735 times
Send a message
https://www.waze.com/wiki/images/6/69/W ... 00k_5c.png
CM: USA
SM: Michigan, Vermont
AM: Ann Arbor, MI & Thunder Bay, ON
WME Michigan

Post by davielde
qwaletee wrote:Orbitc and I just collaborated on an extensive guide to manual segment locks, traffic locks, driving areas, how they interact, and many related things.
Thank you to you and orbitc for drafting this. The illustration is a good addition as well.

As part of refining and proof reading the page, it would be helpful to eventually have clearer information on when locks are applied, approximate values of traffic, how certain road types may or may not apply, etc. Right now, a statement such as "traffic has been building on it" that is used to illustrate that a traffic lock is now going to be applied is too vague. If there is no clear criteria available from Waze staff, questions such as approximately how long before a lock is applied or what volume of traffic triggers a lock should be studied and estimated using the beta editor or come out of countries like Italy where they are currently enabled. Also, how often are traffic locks re-evaluated, does the lock ever decrease if volume drops substantially or just increase, etc...?

Also, the term used in the app is "pave". Do we pave in summer and "plow" in winter? :-)
davielde
Posts: 1219
Has thanked: 454 times
Been thanked: 735 times
Send a message
https://www.waze.com/wiki/images/6/69/W ... 00k_5c.png
CM: USA
SM: Michigan, Vermont
AM: Ann Arbor, MI & Thunder Bay, ON
WME Michigan