Is there a way to add non-approved speed and RL cameras (or even all cameras) to the custom search feature?

But do be careful... it is a tool, not a "fixer"
Some errors reported may be legitimate mapping issues that need to remain for any number of reasons.

But it is a fantastic tool for locating areas that need more study and work.

Non beta here and I'm getting similar "buglets" in the display.
The report seems to catch things, but I'll be at a wider view and might see a blue highlight, zooming in it changes to yellow, or something goes away completely.
Clicking the segment displays the errors properly.
I've also noticed that sometimes a couple of days after I've worked an area, I'll see more errors. Pulling up the segment shows no recent edits, so it was something that Validator missed before.

Doesn't bug me a whole lot... right now I'm using Validator as a tool to clean up some major errors in a fairly wide area that has been neglected, so there is still plenty of work to be done even if a few excess nodes are missed here and there.

berestovskyy wrote:

Taco909 wrote:The report seems to catch things, but I'll be at a wider view and might see a blue highlight, zooming in it changes to yellow, or something goes away completely.

Seems to work fine on non-beta world. A permalink would help to confirm.

It is so inconsistent that a PL would be impossible.
It will appear and disappear at various zoom levels and change as the map is panned, and in some cases display blue on a wide view, then change to yellow or even red when zoomed in.

It seems to have gotten much worse since last weekend and I have not updated any of my scripts, so it could be related to something else.

Edit: https://www.waze.com/editor/?env=usa&lo ... 3,62465924

That is as close as I can get right now. I'm currently not getting blue highlighting at ANY zoom level. It was working last night, so I suspect is is not an issue with the script itself, but in something Waze is doing with the editor or map.
Both segments of this split road (and I agree it should not have been split) have RevCon on Node-B.
My name is on those segments bevcause I cleared the RevCons from node-A, but Grand had an L3 lock.

Okay... here we go.
https://www.waze.com/editor/?env=usa&lo ... 989&zoom=3
Note that at this zoom level, there is an obvious dogleg on the highlighted segments on Dalewood.

https://www.waze.com/editor/?env=usa&lo ... 989&zoom=4
Now zooming in one more step, the "Frazier" street name appears, but the highlighting is lost.
Also notice the numerous other errors that appeared at this zoom level, even though all of the affected streets are visible.

And now at this level...
https://www.waze.com/editor/?env=usa&lo ... 989&zoom=2
The dogleg is gone... only the Dalewood segment remains, Frazier is "clean"

Now at Level 2, the dogleg is there:
https://www.waze.com/editor/?env=usa&lo ... 989&zoom=2

KB_Steveo wrote:

Poncewattle wrote:

sketch wrote:Berestovskyy, could you remove the dead-end U turn check, and make it such that the "unconfirmed turn" checks etc. don't look at dead-end nodes? The ability to edit them has been removed from the editor.

Going to chime in here because I just figured out a way to edit u-turns on dead-ends but want to make sure I'm not breaking something else. Basically I can edit the u-turn on a dead end node by temporarily drawing a short two-way road segment and attaching it to the dead-end. Then I can edit the dead-end (since it's now not a dead-end) to disallow the U-turn. After that is done, I then delete the temporary road segment I just drew. The validator then stops complaining about it.

This also works with "Node A|B: Unconfirmed turn on minor road" where A or B is at a dead end.

It's a hassle. Maybe it's a waste of time to worry about it. Would like to know if it's OK to do this or if creating and deleting a lot of road segments in a short amount of time is "not a good thing."

QW on the end node is even faster

Unless we are in the UK, we are not supposed to do this anymore... we've been asked in multiple threads by various global champs and Waze staffers.
Validator needs to ignore the u-turn, and the "Q" function in JNF needs to be changed so it likewise ignores u-turns if they are at a dead-end.

Poncewattle wrote:

Taco909 wrote:

KB_Steveo wrote: QW on the end node is even faster

Unless we are in the UK, we are not supposed to do this anymore... we've been asked in multiple threads by various global champs and Waze staffers.
Validator needs to ignore the u-turn, and the "Q" function in JNF needs to be changed so it likewise ignores u-turns if they are at a dead-end.

Understand that, and I am treading lightly here so as not to sound like I'm being argumentative, but I've noticed there's other actions that one can do deliberately or accidentally that will change the now-hidden dead-end U-turn. For example, just grabbing the end node of a dead-end and resizing it a little longer or shorter can in many cases change it from a hidden u-turn allowed to a hidden u-turn not allowed.

What I'm seeing here is it turns blue on an unconfirmed... "W" clears the error without using Q.

Now, perhaps it is an unconfirmed prohibited u-turn and "W" simply confirms the no u-turn? No longer being able to see the icon means I don't know. And in some cases, it may not be intentional... dead end, unconfirmed turn at both ends, "W" the junction at the cross street, and JNF will also clear the other node (or it does something to make Validator happy).

And yes, there are ways around it, but that doesn't mean that we should find and use them (or suggest them on the forum) just because we have been asked not to "Q" the nodes.
And yes, I know that new editors will use anything they can to build edits (I was bummed when I found that deleting unapproved speed cams doesn't count ), and this is why WME and the various scripts need to be fixed so the turns are not accidentally (or intentionally) disabled prior to Waze (or the LC) running some kind of global script that enables and locks them.

I'm with you... I'm not crazy about them being hidden, and I've seen routing examples where the "bug" has run drivers down dead ends for no reason. Until Waze is able to implement proper u-turn logic like the commercial GPS units, we are going to have an issue.

Unrelated... How did you get the user title and L2 map avatar?

Poncewattle wrote:Does that destroy the traffic history data on the segment too? The ID number doesn't change at least.

I would think not, given that the procedure for unsplitting a road, or converting a "box" intersection to a "Bowtie" on split roads is far more complex and are the preferred procedures for making those changes.

I suspect that as long as you do not hit "save" while anything is disconnected or disabled, data is retained. Obviously, box-to-bowtie is going to require a complete rebuild of the junction data because you are merging as many as 32 turn movements spanning 100ft into 24 at a single junction.

PesachZ wrote:All the U-turns and unconfirmed turn highlighting has been removed. Thank you.

This is a big step in the right direction.

We have an issue remaining that is unrelated to Validator:
WME will still react to the "Q" command on these end nodes, whether the command comes from a stripped editor or JNF. While the editor would have no reason to use the command, JNF can apply an unintended "fix" to the termination node. I'm sure there are a few scripts floating around that were written by editors for their own use... these can still pose problems.

If WME would simply ignore any turning-related keyboard command on a junction with only one attached segment, it would solve all of the problems with outdated scripts and uninformed editors hitting "Q" on the end node.
I had hoped that when the arrows went hidden that this would happen, but judging by the reporting from Validator, that is obviously not the case.

On uninformed editors, I would hope that not many who are using Validator are unaware of the proper way to handle dead-ends, but I'm sure there are more than few who rarely check in on the forum (at least until last night). For this reason, I can see the point in having an expiration date in the script. Not everyone has their scripts set up to auto-update. It goes along with the "Internet of Things" line of thought to have a literal built in self-destruct on connected devices to prevent older, insecure items like thermostats and appliances from being hacked and causing damage to the consumer or wider areas of the network (imagine a connected thermostat and furnace or water heater that someone hacks into and disables the safeties and turns them on full temp)