voludu2 wrote:

berestovskyy wrote:WME Validator F.A.Q.
New! Search for a specific username
Validator does support a search for a specific username. Click "search" tab and put a desired username(s) into the "Updated by" field.

I really like having WME Validator double-check my work.
This is a really useful feature. It would be really useful for mentors to be able to search for their mentees' usernames, too.

Thanks for all the effort you have put into this tool.

A mentor can request a report on their mentee in an area from a champ mentor/RC, they might be willing to help.

SuperDave1426 wrote:

doctorkb wrote:

SuperDave1426 wrote: Ok, thanks. I wonder if he can be persuaded to add State Managers, at least within the states they manage....

I doubt it. I suspect that he's using a "CM" flag that is applied to a user's record by the Waze system.

To expand it to anyone else would have to be to "AM" or everyone... unless he did a username-by-username validation.

Oh, maybe I misunderstood then. I thought that I had read somewhere that Waze actually created an official State Manager designation in the system. You're right, if all they did was just make us AMs with an area the size and shape of our states, then he'd have no way to tell the difference.

doctorkb wrote:AFAIK, the SM designation is just a large AM area, plus some "how we do things" stuff... nothing in the database.

As OrbitC said here

OrbitC wrote:

So what is the status on finalizing the details of the US SM and the SM wiki page? Is it still in a discussion period with Waze?

Also, if an SM registry is to be made, here is the list of all the known/registered SMs in the US.
State Manager USA

Waze added State Manager (SM) as an official role.

Waze said:

"we want to add it as an editing role - someone who gets editing rights for a polygon, in this case a whole state and let the community decide on his community role, as you defined it"

It's a role that will be approved by the community. It'll have to be someone who's active in the community.

Sorry for the coded Klingon message before

However a username validation against members of the state managers forum usergroup may not be to complicated, although It might mean that the list is only updated with script updates, as this script doesn't communicate with the internet.



Sent from my SAMSUNG-SGH-I337 using Tapatalk

sketch wrote:

Taco909 wrote:Okay, I'm not sure if this belongs in Validator or if it is a WME bug.

With the week's changes, my first custom highlight is now nul elevation (and when I clear it, it comes back on next reload)
That's fine, I can live with it... but it seems that for the most part, I only see it after I've edited a segment... such as after deleting a connected segment or unneeded junction node.
For the unneeded junction node I would expect the purple highlight to take precedence, but I'm seeing others that were not highlighted before a save and pop up green after saving.
In one case, after a save, a street two segments removed from any editing popped up nul.

At first I thought I still had highlighter set to display recent edits, but confirmed that it was not set.

They are legitimately nul elevation, but I have not yet been able to confirm whether or not they were nul before the edit-save operation.

The only reason you started to see null elevation is that JNF wasn't working properly for a while, and JNF suppresses null elevation (shows 0 instead). So with JNF suppressing null elevation, Validator didn't see it, and couldn't show it.

Taco909 wrote: Please be aware that some apparent overlaps and spurious geonodes were placed intentionally for TTS wayfinding assistance.
It is not uncommon for a junction to have a 90 degree turn, but the geonode is placed so closely that it appears to be a shallower angle. These are intentional to force a "Turn ____" instruction rather than "Stay to the ____"

Likewise, there may be some cases where it is desired to execute the turn instruction early, but to overlay the departing segment onto the feeder segment for a short distance.

Apparent spurious geonodes, yes, but 90° turn-instruction micro-doglegs wouldn't show an "overlap". The overlap highlight only shows when the segments run on top of each other for a moment, so making such a dogleg would remove that highlight, unless of course the segment overlapped the other segment later on.

As for the early instructions, IMO it's better as an editor to lay the departing segment just next to, but not directly coincident with, the continuing segment.

In short, IMO the overlapping check is still quite useful to detect improperly-set "dogleg" constructions (usually where the geonode was accidentally snapped to the other segment) and to let you know to give the latter scenario just a little bit of leeway.

As far as the highlight, my experience it only checks for two segments connected to the same junction, at the same turn angle . So am apparently overlapping segment with a dogleg wouldn't get a highlight, provided the dogleg caused the two segments to have different turn angles.

OTOH it's never a good idea to lay two segments directly over each other, as it makes it much harder to detect and edit later. It is unnecessary because the client has a max zoom level of 6, and therefore any segments separated by less than a few meters are visually distinguishable in the client display.

Even in the very trade case where you purposefully want to create two segments which fully overlap, including identical turn angles (understanding the implications this will have to routing instructions - it can completely suppress instructions), you only need the first bit of the segment to overlap, ascertaining you can place a geometry node to shift the rest of the segment over a meter or so, to run adjacent to each other.

Sent using Tapatalk for Android 4.4.2

sketch wrote:

PesachZ wrote: As far as the highlight, my experience it only checks for two segments connected to the same junction, at the same turn angle . So an apparently overlapping segment with a dogleg wouldn't get a highlight, provided the dogleg caused the two segments to have different turn angles.

Definitely not so – I see it often with very low but nonzero angles, for example in ramps with long acceleration/deceleration lanes where the last geometry handle is pretty far from the junction node but pretty close to the other segment (on the other axis). This comes up mostly when I'm editing freeways.

I should have clarified, when I said at the same turn angle, I meant ±2°. So to rephrase "a segment will only be considered overlapping another segment, if A) they both share at least one junction node, AND B) they have identical turn angles (± 2°) at the shared junction node. If there is a dogleg changing the angle of one segment so it no longer has the same angle (± 2°) as the other segment at at least one shared junction node, then it will not be considered overlapping even if the entire middle of the segments are directly on top of each other"


I reiterate it unnecessary for segments to be laid directly above each other, and it makes for harder editing in the future, very near adjacent placement should do fine, and if an overlap is desired only the very beginning would need to overlap.


Sent using Tapatalk for Android 4.4.2

Such intricate edits deserve to locked to prevent 'fixing'. If I ever (and it's rare) make an intentionally overlapping segment, I all my RC to lock it at rank 6.

Sent using Tapatalk for Android 4.4.2

roadtechie wrote:Maybe this has been brought up before. But, I would love for validator to flag any cameras that are in states that do not allow cameras. I live in Indiana which does not allow any cameras at all in the state except for toll booth enforcement. If Validator would flag all of the cameras it would make my daily deletion of cameras a LOT easier!

Are the cameras you are deleting being confirmed by other editors, or just reported?

Besides if all cameras are illegal isn't the presence of the icons enough of a 'flag', unless you are looking for a list of cameras in a report.

Sent using Tapatalk for Android 4.4.2

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.

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.

Taco909 wrote:

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

berestovskyy wrote:...

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