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.

sketch wrote:
<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: Select all

${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])|(.*)/

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.

Definitely not one of my favorite abbreviations

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.

Glad to see this back!

The new editor release killed validator!!!