Mikenit: the problem is they don’t do what people who use them expect them to.
They should route like parking lot roads, but they route like streets.
Exactly.
Right, and with highlighting, we can find them and set them as they should be, before the mass-change-to-whatever (likely “street”) happens.
Like another who posted in this thread, I’m also using a custom check to find them. And I agree; it would be nice to free that slot up since we only get two of them and this really should be something that Validator just checks for among the other things it checks for.
If there’s something more urgent that’s broken, then yea by all means fix those broken items, but adding this check should also happen.
Which is a problem. So, Mikenit, no, the “response” is decidedly not nothing.
Plus, we’ve been explicitly told to not use the service road type, so we should be looking for them and setting them as an appropriate type. Having them highlighted, even as just a note type, by the Validator would help us a lot towards that end.
Until the URs start coming in because roads that are currently penalized will become routable.
Most “service roads” that I have encountered should be classified as PLR, Private, Walking Trail, Dirt/4x4… or not even mapped. They are generally behind locked gates and never available for the public to drive on.
Just to note I’ve come across a bunch of “service roads” which should have been mapped as Primary Streets. On the east coast (at least in NY metro area) we refer to frontage roads colloquially, and even on some DOT signage as “Service Roads”, which leads lots of editor to choose the Waze ‘service road’ type for those roads instead.
We have people marking service roads around… car services 
Sure. There is no problem with service roads. But there a problem due a bad mapping and wrong application of service road. I agree. Put the check. :lol:
Does it detect revcons? I thought so, but I have not detected any reverse connectivity with it lately, even on a segment where someone else could see the revcon, using toolbox.
Memory Problems.
When I have validator enabled in Chrome, the memory in the WME browser window quickly gets out of hand. When I start up WME without validator, the window uses 130-160 M, but when I run validator, it quickly goes to 200. After an hour or so, it goes to 300, then 400. Then the PC starts doing a lot of paging and things slow down, and I have to close and restart chrome. sometimes, Chrome starts complaining that it has run out of memory. Or it crashes altogether.
This is recent behavior. I never noticed it before just recently. The most recent things I did were to install tampermonkey and start using the Chat add-on. Of course, waze has also made recent changes to WME…
Has anybody else had problems with validator recently?
That is a Chrome memory management problem, Validator just makes it happen more quickly.
Even without Validator running, constantly opening and closing new tabs (like from URO+ links) would cause Chrome to slow to a crawl and crash after working 15 or 20 URs.
On detecting Revcons, it used to, but has not yet been updated to reflect the new changes in WME.
Toolbox does now pick up on them so Validator is redundant, however, Validator does NOT report Revcons identified by Toolbox in the report the way it used to, so they have to be manually searched for.
Node A on this segment is being flagged as not needed, even though it is there to show a legitimate turn restriction. The map is actually accurate as is, but the node is being flagged by validator.
This is a 2-way road segment with a barrier in the middle only allowing eastbound through traffic, however it is still a 2 way road on either side of the barrier. Westbound traffic is restricted through this junction.
I have not been getting Validator flags for the “red” highlights since the WME dustup a few weeks ago that “broke” many of the scripts.
I am not getting highlights, or entries in the reports, for no inbound connection, no outbound connection, and of course, revcon. All I’ve been seeing is extraneuous nodes and “no connection”.
For your situation, would it not be appropriate to add a 5m one-way segment?
Adding an extraneous segment would stop the validator flag, but That adds two nodes instead of one into the database. I think Validator should compare segment properties across a junction, an not deem it unnecessary if it is separating two segments which different properties, (i.e. lock levels, elevation, name, alt name, type), as well as any turn restrictions including allowed u-turns.
Guys,
Everything about connections is not working since the last WME update. Some checks I had to disable manually, but some checks (like those unneeded node A/B) just silently lost some of their functionality.
I’m sorry about that, but I’m busy at the moment and simply have no time to fix and test it. I’ll be busy till the end of October or so 
I’m also looking into some options to fix this sooner…
PS. For the unneeded node A/B you can change something insignificant in the segment’s properties as a workaround. Try to change lock or alt name for instance…
The lock doesn’t seem to be enough of a difference to stop the validator flag for unneeded node
Sent using Tapatalk for Android 4.4.2
Berestovskyy: BellHouse fixed this issue (with nodes) fairly quickly in TB. Perhaps he might be able to do the same for Validator, if you’re interested in help…
I don’t think turn restrictions were ever enough to avoid a flag… in fact, it would result in a “red” inbound/outbound connectivity warning flag rather than the “blue” extra node flag.
The connectivity flag could be avoided by the addition of the one-way segment and enabling the u-turn.
I thought that lock level was enough to avoid the extra node flag. Elevation and name are unless something changed on elevation lately.
Edit: Just verified, elevation is enough to avoid the flag. Lock is not.
The red flag would be expected, the blue unneeded flag I’m asking to be fixed so it considers turn restrictions and allowed U-turns
Lock level didn’t do it for me here
Sent using Tapatalk for Android 4.4.2
Make sense, though I don’t like leaving the red flag if there is a legitimate way to clear it, if only to prevent a new editor working from a Validator script from opening the restriction (which would then show the blue alert, so he then deletes the node)
That’s why I brought up the one-way segment. It avoids both alerts (if the u-turn is set) at the small cost of the time penalty for the one extra junction (and this situation is likely going to be on a small street that we probably don’t want to encourage detour route-through anyway).
I’ve been using the one-way segment to make private driveways on gated communities exit-only. It avoids routing non-residents into the closed gate, once inside, the gates typically open automatically to allow exit, and residents with an opener or code will know they can use the gate and can ignore Waze directing them to the guard shack.
Simply having a turn restriction on a single node should cause any editor to do a double-take. First look (in your case) shows a high ranking editor name, but that could be assumed to be from FC. A more experienced editor would move in closer on SV and notice the lack of UR to confirm… the one-way segment would provide a flag to a less experienced editor that says “This is not a mistake, I did this for a reason”
It would be very helpful if WME were to include a comment field on junction and segment ID database entries. If that were done, then Validator could include the comment in the report page on any alert.
Validator flags are just that, flags of a potential error. The reason validator doesn’t actually did anything is because they want human editor eyes to actually confirm that something needs to be fixed first. Looking at the segment, seeing the restriction and the rank lock, should tell any editor to confirm on satellite or street view before changing it, or send the previous editor a pm. An editor who doesn’t know to do that on a locked segment, usually doesn’t deserve that rank. On a side note we could also leave a [NOTE] UR describing the details, but I felt it wasn’t necessary here with the clear GSV images.
Sent using Tapatalk for Android 4.4.2