[Script] WME Validator 2020.04.12 (PLACES BETA)

Discussion for the unofficial, community-developed addons, extensions and scripts built for the Waze Map Editor.

The official index of these tools is the Community Plugins, Extensions and Tools wiki page.

Moderators: Unholy, bextein, Glodenox, JustinS83

Forum rules
Discussion for the unofficial, community-developed addons, extensions and scripts built for the Waze Map Editor.

DO NOT START a new thread unless it is about a new idea. Keep discussion of existing tools within the main thread for that tool.

The official index of these tools is the Community Plugins, Extensions and Tools wiki page.

Re: [Script] WME Validator 1.0.2 / 04.07.2014

Postby PesachZ » Sun Aug 03, 2014 2:12 am

Poncewattle wrote:
CBenson wrote: I find it now somewhat critical that this indication remain in Validator so I can troubleshoot and report problems with enabled or disabled dead-end roads.


Right now the validator reports it as a (yellow) warning if the u-turn is enabled to get around the bug documented in the wiki that says "Due to a bug in Waze, we need to make sure that Waze thinks that a U-turn is not allowed on a dead-end, even though in reality it must be." (which was before they hid it from us of course):

https://wiki.waze.com/wiki/Map_Editing_ ... nd-streets

What I am inferring from what I hear you saying is, iff Waze ever fixes that bug, then the validator should then be changed to report it as an error for the OPPOSITE condition -- if the u-turn is in fact disabled, since after the bug is fixed the u-turns in most cases should in fact be ENABLED.

Am I understanding this right?

It would seem given the new stance from Waze that this wiki should be changed. I will bring this up in the wiki update forum.

EDIT: Scratch that, the wiki you quoted has already been updated to read
wiki wrote:As of July 2014, U-turns at dead ends or cul-de-sacs, no longer need to be adjusted in a particular way. WME no longer provides a link to adjust it.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.3 / 04.08.2014

Postby PesachZ » Mon Aug 04, 2014 5:33 pm

All the U-turns and unconfirmed turn highlighting has been removed. Thank you.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.3 / 04.08.2014

Postby PesachZ » Mon Aug 04, 2014 6:34 pm

doomedtx wrote:FWIW, in my work Chrome install I had to remove the script and re-install it. There was no obvious way to upgrade from 1.0.2 to 1.0.3. It's probably because the browsing restrictions at work prevented automatic upgrading.

(So I can edit during my lunch break and never while I'm being paid to be here) ;)

Chrome updates automatically on a schedule, if you want to force an update you have to go into the Extensions tab, enable developer mode, and click the button at the top to update extensions. Otherwise it will update on its own after several hours.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.3 / 04.08.2014

Postby PesachZ » Mon Aug 04, 2014 8:01 pm

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


Could we please have the highlighting of dead-end u-turns turned back on for the UK, please?

As discussed elsewhere on the forums, we still consider them a real problem. We had Waze mass-disable every u-turn on the UK map. Unfortunately, the routing engine keeps enabling new ones where the disabled u-turn is "soft". With the arrows already removed, it will be difficult to diagnose problems involving u-turns unless we can see them, not to mention the routing problems we still see them causing.
anyway...why are these features removed?

please explain

Because the Waze staff Ohad and Noam have asked us in the feedback thread for the WME v1.6 to no longer manipulate the turns on dead end nodes. The functionality to adjust those U-turns and soft turns has been removed from the WME UI with the latest to discourage editors from trying to change them, but validator was still highlighting them as a problem. Being highlighted was causing many editors to try and find workarounds to change the turns to keep validator happy. So they were removed from validator, to comply with the vision Waze staff have for the map.

For more detailed info about why this change has been made see the WME feedback thread.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.3 / 04.08.2014

Postby PesachZ » Sun Aug 10, 2014 2:14 am

ispyisail wrote:
No, not yet anyway, as this goes against staff's express wishes. So far I believe the UK is the only country to get any sort of special permission from staff to leave them off.


Can you link to any reference for this?

I just want to go through the logic

and the reason why wazeHQ thinks it OK for the UK?

The conversation regarding u-turns at dead end segments has been happening in the WME v1.6 feedback thread. Here is the latest posting from staff regarding the UK exception



redviper26 wrote:
Dave2084 wrote:This whole conversation is at odds with the understanding the UK Champs have regarding dead end U-Turns.

The UK Champs asked Waze to run a job a few months ago which disabled every dead end U-Turn in the UK. It soon became evident that (misguided) users would enable them again and re-introduce the routing errors that come with them since the Waze client has no U-Turn instruction. This is one of the reasons (if not the main reason) behind the disabling of U-Turns on a dead end node in WME.



The situation in the UK is unique, and we did disable U-turns there following the community's request. For other countries, U-turns should be left as they are, and we intend to enable them in the future.

Thanks,

Noam
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: WME Validator F.A.Q.

Postby PesachZ » Fri Aug 22, 2014 5:12 pm

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.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.3 / 04.08.2014

Postby PesachZ » Fri Aug 22, 2014 6:40 pm

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:[quote uid=16781248 name="Fredo-p" ]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 :)[/quote]



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
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.4 / 24.08.2014

Postby PesachZ » Thu Aug 28, 2014 3:29 pm

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
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.4 / 24.08.2014

Postby PesachZ » Thu Aug 28, 2014 5:31 pm

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
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Script] WME Validator 1.0.4 / 24.08.2014

Postby PesachZ » Thu Aug 28, 2014 7:31 pm

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
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

PreviousNext

Return to Addons, Extensions, and Scripts

Who is online

Users browsing this forum: jm6087, mudge42