[Script] WME Validator v2021.3.5 (+ PLACES BETA)

Don't forget that WME Toolbox incorporates much of JNF, including the Q functionality, so test this with Toolbx and JNF both off. It will probably work anyway BUT with the side effect of making all junction traversals illegal (all red arrows).

It would appear that Waze has decided that U-Turns and dead-end U-Turns are not going to be editable any more. Personally, I think that's a bad idea at intersections, since how can you indicate where a U-Turn is actually legal to perform for the routing engine? But that's another topic.

Since that seems to now be the case, is there any chance that Validator can be updated to no longer highlight roads with "Unconfirmed turn at node {A|B}" when node {A|B} is a dead end?

I just tested this. You can still make it a hard no u-turn by clicking on the end node and typing "q". This works while running JNF and without JNF installed. (I just tested both cases.) So you just need a keyboard to edit them.

Krikket

I went straight with "V" unmodified

Does the keystroke automatically update? Mine had stayed at Shift-W (interfering with Waze's new Shift-W for closing SV) until I manually changed it. I checked, and I did have 1.0.2.

04.07.2014 v1.0.2:
- Complete Hebrew translation thanks to gad_m
- Minor UI changes for right-to-left languages (please report any issues)
- Changed keyboard shortcut to 'Alt+V'

+ Two new external translations:
Note: you need to install them along with the main Validator package using Tampermonkey

• Czech (Čeština) by petrjanik, Kebb01, Zirland:
  For Greasemonkey/Tampermonkey: GreasyFork.org
  Forum thread: forum link
  
  
• Slovak (Slovenčina) by ChoseS:
  For Greasemonkey/Tampermonkey: GreasyFork.org
  Forum thread: forum link

Super-mega-cool! Thanks guys!

The whole U-turn thing has become another source of frustration and confusion... well, I should say, and even greater source, it always was a source. The guidance is ambiguous, the way it works is unclear, the advice seems contradictory, and the implementation of the temporary fix counterintuitive and perhaps counterproductive.

I need a Level 5 Map Editor to fix this error. When turning off of Rand Road onto westbound Capri Drive, at the very next intersection with an unnamed road to runs NNW, at that point Capri Drive becomes ONE WAY in the east bound direction. Waze thinks it's a two way street and tries to route me down that street. https://www.waze.com/editor/?lon=-1.318 ... 597&zoom=0

This is not the place for that post. Please post to the unlock forum instead.

The reason you get multiple segments types highlighted for /1/ is that it also matches /10/../19/ and /21/. You need to either use a matching separators before/after the template and expression, or use the explicit start/end codes in the expression.

Note that [A-Z][A-Z]* is equivalent to [A-Z]+

* means 0 or more
+ means 1 or more

The "hard" part of the second one is that we are looking for two things, either a lowercase at the beginning, ro a space and a lowercase anywhere. We can easily fix that by looking for both separately, but a trick is to put a space in front of your template, so that it is as if every name starts with a space.

So, for your first one, all you need is ("template"="regexp"): "${street}"="[A-Z]{2}" which says street name contains any capital letter somewhere followed immediately by any capital letter. It doesn't matter where in the string it occurs, regexp by default looks throughout.

For your second: " ${street}"=" [a-z]" - there is an space after each opening quote. Again, looks anywhere for a space followed by a lowercase, and since in the template we start with a space, that will include if it is at the beginning - Waze doesn't have a space there, but due to the template, t is the same thing.

Now we can combine the two:

" ${street}"="( [a-z])|([A-Z]{2})"

The parentheses make each statement stand by itself without interfering with the other. The bar | says "check for for or the other, either matches." I'm not sure if the parentheses are needed, I don't recall offhand whether the {2} will try to apply itself to the whole thing or not. I think it doesn't, but I'm lazy.

I have not tried any of the above, so I might have messed up somewhere, but give it a whirl.

*Edit: Note that the second expression in the regexp should NOT have a space before it, unless you want to limit reporting to cases where the two caps are the beginning of a word. For example "MaIN St" only matches as a problem if you leave the space out.

SuperDuh-ave? DOes that street name meet standards?

Daniel,

Are you talking about the real-time highlighting, or the "Show report" button?

Ignore this post. I was incorrect. I believe the failure is that the assertion must match (or negatively, fail to match) the string immediately at three cursor position.

<snip>

${altStreet[#]} prints a list of all alt streets separated by the # character (also arbitrary, like the colon above). I added that stuff in and removed some superfluous parentheses. I'm not sure if this will work, because I'm not very good with negative lookaheads, but it's closer.

Code:

${typeRank}:${altStreet[#]}
/(10|11):.(?!(Rd(#|$)))*(#|$)/

So I decided to try this as an intellectual exercise because I took too long a nap today and am now hyper.

1) Usually, when having trouble with RegEx, best to build the "components" first and test each piece, then you can bring them together afterwards without worrying "which one did I get wrong." So, perhaps start with testing only the alt names portion - ${altStreet[#]} as the template, /.(?!(Rd(#|$)))*(#|$)/ as the regex (using sketch's code)

2) In sketch's code above, there is a single period before the negative lookahead. That would indicate a single character before the negative assertion. Not sure why you would want to do that. The * after the parentheses will apply only to the parenthetical, not the period.

3) * means "zero or more times" - in otehr words, eat up as many occurrences as you find, but don't worry if it isn't there. I don't know why you would ever have * after a negative assertion. Im not sure it can even be applied to it, because there's no point to "zero" times of a negative assertion, that would probably mean it never fails. And if it succeeded, once is enough, we don't care how many times it appears, because assertions don't eat characters out of the string , they just check if they exist, and continue where we already were in the string. So I'll just assume we really only need: ${altStreet[#]} as the template, /.(?!(Rd(#|$)))/

4) Finally, my simplification of sketch's code above means as follows:

Take an example segment with two three names: Alt Ave, Other St, Any Pl. The template will expand to: Alt Ave#Other St#Any Pl

Or, as Regex sort of sees it, ^Alt Ave#Other St#Any Pl$

The Regex starts with a period, matching any character. Here, it will start by trying to match the A of Alt, and succeed. The remainder of the string is: lt Ave#Other St#.

Next, it has a negative assertion, (?!(Rd(#|$))). The regex string being checked for "not there" is (Rd(#|$)). This means, "check the remainder of the string for either Rd# anywhere, or plain Rd at the end only." Since Rd does not exist in the string anywhere, the string is not found. This being a NEGATIVE assertion, this failure to find the string means the REGEX SUCCEEDS. This matches, and would be reported by Validator.

This would be true if there were no alt names at all, except that your period forces it to find SOMETHING to succeed. So I guess the period is just there so that it only highlights roads that have something in alt names, but don't have any alt name ending in Rd.

Now, let's say the alt named were Alt Rd E and Other Rd. The template expansion would be:
^Alt Rd E#Other Rd$

The processing would be:

. eats the A of Alt Rd E

Negative assertion looks for Rd, finds it at "lt Rd, continues looking for # or $ immediately afterwards. The space (between Rd and E) matches NEITHER # nor $, so it fails at this point... but regex continues looking.

Negative assertion now find Other Rd, looks for # after the Rd, find end of string (no match), then tries alternate of $, which does match the end of the string. So the string inside the assertion was found, and since this is a negative assertion, it FAILS.

Now, if I don't get bored, I guess I can try this on a few test segments.





street}:${type}type}:${lock}/.+:2___0$/!/([3]:[^5]|[6]:[^4])|(.*)/