Switch to full style
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.

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.
Post a reply

Re: [Script] WME Validator 1.1.0 / 29.08.2014

Fri Aug 29, 2014 5:19 am

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

Re: [Script] WME Validator 1.1.6 / 06.01.2015

Mon Feb 23, 2015 5:37 pm

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.

Re: [Script] WME Validator 1.1.6 / 06.01.2015

Mon Feb 23, 2015 5:38 pm

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

* means 0 or more
+ means 1 or more

Re: [Script] WME Validator 1.1.6 / 06.01.2015

Mon Feb 23, 2015 10:06 pm

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.

Re: [Script] WME Validator 1.1.6 / 06.01.2015

Fri Feb 27, 2015 1:53 am

SuperDuh-ave? DOes that street name meet standards?

Re: [Script] WME Validator 1.1.7 / 06.03.2015

Fri Mar 27, 2015 2:41 pm


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

Re: [Script] WME Validator 1.1.7 / 06.03.2015

Mon May 04, 2015 5:03 am

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.

sketch wrote:

${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.

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.


Re: [Script] WME Validator 1.1.7 / 06.03.2015

Thu May 07, 2015 3:37 am

Hi, Berestovsky,

A small recommendation. Instead of having a single cutoff date, have a warning date first. This way, you will no there is about to be a problem before it happens, instead of having people lose access for even a short time.

Re: [Script] WME Validator 1.1.14 / 17.11.2015

Mon Nov 23, 2015 12:18 am

Definitely not one of my favorite abbreviations

Re: [Script] WME Validator 1.1.15 / 13.12.2015

Fri Dec 18, 2015 4:48 pm

I'm sure we all appreciate the script very much. We're also allowed to voice an opinion on its quirks (after giving thanks of course).

I think part of the problem is that the author doesn't really try to set expectations, or communicate much in general. Yes, he has that right. But it invites the kind of discussion that's ben taking place.

As long as the tone remains neutral or respectful, I don't think anyone here should be dinging a fellow editor for posting his thoughts here, or even complaints.
Post a reply