[Script] WME Validator v2020.11.1 (PLACES BETA)

[krikketdoug]

I'm not sure how much of the rules support this, exactly. Railroads are to be set at -5, certainly, as are Walking Trails (if mapped at all), I believe, but a Pedestrian Boardwalk shouldn't always, necessarily. I think a lot of these rules are in flux.

I could have sworn I saw somewhere on the Wiki that all non-drivable roads should be -5 (except airline runways, which should be a 9) but that might just be a local agreement. There is a reason I'm a timid editor when I'm outside my normal area.

3> Another check that would probably have to be handled on the country level now that Landmarks has transisitioned to Places is a check on the new Places markers versus what the rules say they should be. For example, for a while a religious site was permitted while a simple church was not. On the other hand many editors concluded that any site that had hundreds of worshippers visiting it every day or was over a hundred years old (Hey! I'm in America! Here that is a long time!) or... You get the idea. In each country there should be (eventually) a list of approved typed of markers in the Wiki that could be used to compare what is used. [edited to remove additional unnecessary examples]

Much simpler under the new rules, if I understand everything correctly. Just mark them all places(points) instead of places(areas). [edited to remove a reference to the unnecessary examples]

I don't mind the idea, but I think Places is still too young to start incorporating things into Validator about it -- especially in the rest of the world.

Agreed. But it is a thought for the future as Places matures.

[krikketdoug]

1> Walking trails and other non-drivable road types that have a elevation of something other than -5 be flagged.

You can use a custom check in Validator for that:
template: ${typeRank}:${elevation}
regexp: /^5:(?!-5)/

Thanks for the code. Now when I get the round tuit to figure out how to use the custom check...

But in fact at the moment Validator does the opposite. In some countries it highlights walking trails with elevation -5 (check #105).

Okay. Definately a country specefic thing then...

2> Now that the US is moving to a Functional Classification system,

I did not hear about US Functional Classification, so I can't comment this, sorry.[/quote]

Sure you can! That was just the reason why I thought of the check, as in my area a lot of road types are changing and sometimes things are missed. That doesn't invalidate the concept elsewhere.

[kentsmith9]

I believe the elevation 9 runway thing was suggested by me in another thread — because if runways interact with other roads at all, they'll be on top.

That very well could be. I never touch them, so I didn't make certain to memorize that detail. I don't even touch walking trails, and other non-drivable stuff other than to correct what's already out there by the established guidelines. And then I double-check before I do.

[krikketdoug]

1> Walking trails and other non-drivable road types that have a elevation of something other than -5 be flagged.

You can use a custom check in Validator for that:
template: ${typeRank}:${elevation}
regexp: /^5:(?!-5)/

By chance is this one of those features linked to editor rank? I've looked about my system and haven't been able to find a way to do this.

But in fact at the moment Validator does the opposite. In some countries it highlights walking trails with elevation -5 (check #105).

For the first time I ran across a road that needed to be added, where I had to worry about elevation. Long story short, I double checked the wiki. Aside from the link I believe was previously referenced, https://wiki.waze.com/wiki/Road_types/U ... .2FTaxiway (and yes, that is US specific) I also found: https://wiki.waze.com/wiki/Elevation#Road_elevation

The reason I mention it here is because (I believe) the effort is to get this wonderful extension to match the Wiki. I have no clue how the ROW uses elevation, but since this might be relavent, I thought I'd point it out in an attempt to be helpful. Hopefully I succeeded. If I didn't, please accept my apologies.

[krikketdoug]

An idea for another invalid street name check, that might be workable...

I was out on a drive and I heard a couple of times at different streets, "Turn right on Street Charles Road". Kind of obvious what the problem was when I thought about it. St. is the abbreviation for Saint and Street.

Given that Street would only be used at the end of the street name, but Saint would be used after the directional (if any) and before the name, could Validator look for St in this context?

Just a thought.

[krikketdoug]

This discussion has happened so many times. It's a problem. Go find it on the rest of the forum if you aren't convinced yet. There's no need to do it again.

Then let me give an answer that fixes the problem.

https://wiki.waze.com/wiki/Junction_Style_Guide#Loops (Edited to add the following: Look under Loop Save Errors)

Fortunately for me Junction Node Fixer (JNF) still works, so it simplifies this process a lot. Click on the double-node, hit q, and the new node appears. Add one more node, and the problem goes away. By hitting q, yes, you get about 15 edits. Look at the guide for the reason why.

Hope this helps!

Krikket

[krikketdoug]

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

[krikketdoug]

I don't know. I'm running a non-standard system (Mageia Linux, Chrome (not native to Mageia), plus the plug-ins.) Try it after telling Chrome to disable the extension and reload the page? Maybe instead of a q-w for a junction, use a w-q?

Just random thoughts... [Edited to add the comment that if something doesn't work, you can always undo it!]

Krikket

[krikketdoug]

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).

For what it's worth, I keep Toolbox turned off almost always because I've found (and had it confirmed on the forums) that it interacts badly with URO+ after a bit of time. If I need it for a specific function, I'll turn it on, and then shut it off again.

So the use of exensions may also play a part...

Krikket

[Kuhlkatz]

It definitely gets my vote for its own tab. The Me tab was fine in previous WME releases, as there was nothing else on it.
In its current state, it clutters the screen and introduces double scroll bars for tab content that can fit on one screen.

Sent from my HTC One using Tapatalk