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

[berestovskyy]

In London we use this type of construction to work the time based operation of our congestion charge.[...]is it possible to prevent these types of segments being raised as issues?

It's not a problem to suppress the "Overlapping segments" either for lvl 6 locked segments or if one of the overlapping segments has a time based restriction.

Please note that Validator users have the "Exclude non-editable segments" option set by default, so low-level users do not see those errors since the segments have lvl 6 lock.

Please discuss the options I mentioned above with the other CMs and let me know shall I exclude lvl 6 locked segments, segments with restrictions, both or neither.

Thanks!

[berestovskyy]

I notice that the YELLOW soft-turns-on segment error can sometimes hide other RED or BLUE warnings

I guess the bug was introduced with "auto-disable slow checks on zoom levels 0-3" in 0.8.2.

Thanks, will be fixed.

Node X - no xxward connectivity

It makes sense, will be renamed.

A bowtie U-turn is not too sharp.

Validator does not report too-sharp bow-ties. But this intersection is not a bow-tie.

Have a look at the Classification of crossings, DSSS:

you may want to join the double lanes into a single node, creating a sort of half-mapcat-bowtie

If you do so, Validator will detect the "half-mapcat-bowtie" and will not report "too-sharp turn". Alternatively, you can make the turn more than 30 degree or just ignore the warning.

Sure, Validator can look for similar street names, but I guess it will eliminate any use of this check, because the check basically was designed to detect situations like this...

[berestovskyy]

What error would ever be missed by permitting this specific configuration?

The main purpose of the "Too sharp turn" is to detect such the situations. Here is the original proposal by robindlc: this thread link It comes handy for connectors on intersections. For instance, left turn from the connector should not be enabled here:
[ img ]
As in many other situations.

You have few options:
1. Disable the u-turn.
2. Make the u-turn at least 30 degree (i.e. less than 150 degree of course deflection).
3. Split the road right on the intersection (i.e. make a half-bowtie).

Any of the above will make the Validator happy.

[berestovskyy]

2. Widening the U-turn could give rise to "Stay right" instructions for traffic going straight through.

I guess not, please see How Waze determines turn / keep / exit maneuvers

if s-out is determined to be the best continuation of s-in, the instruction is: 'CONTINUE'

Since "straight" and "u-turn" directions both have the same name and road type, the "straight" will always be the best continuation because the angle is more straight. Assuming the wiki document has no mistakes...

[berestovskyy]

If the angles are too steep (45 degrees or greater) a driver traveling along one of the one-way segments may be told to "turn" or "stay" at the intersection instead of receiving no instruction.

45 degrees for "straight" on Y split mean 90 degrees for U-turn. So you have a range between 90 and 150 degrees for U-turn (60 degrees spread), which will make Validator happy as well as will not create any instructions for "straight".

1. The junction does not have a two-way street splitting into two one-way streets departing at less than 60 degrees from the two-way and within 90 degrees of each other. Or,
2. The names of the one-way lanes do not begin with the name of the two-way street.

An at-grade connector is a one-way street that is usually unnamed. The duplicate right turn on the two-way portion should be disallowed.

At-grade connector was just an example. There are Y-splits right before the intersection/roundabout as well as a two-way ramp Y-splits etc. etc.

Here is an example of a two-way primary street splitting into two one-way streets and the names are all the same: permalink

Sorry, at the moment I see no way to implement your proposal

Please spread your U-turn and make it between 90 and 150 degrees (i.e. 30-90 degrees). You can also disable the warning by putting

Code: Select all

!120,!121,*

into the Search->Reported as field.

Thanks!

[berestovskyy]

14.03.2014 v0.8.3:
- Updated #106 for PL 'Unneeded name on one-way Ramp'
- Renamed some checks to 'Node A/B: ...'
- Fixed: auto-disable slow checks on zoom levels 0-3

[berestovskyy]

Please have a look at the updated "How to create/install/update localization packages for Validator":
forum link

Let me know if you have any further questions regarding the localization.

Thanks!

[berestovskyy]

The thing is that even if I move the #123 validation on #124 it doesn't work that either, and it worked on #123.

The check #124 does not exist and you can't simply create it with localization pack

But I can create a bunch of disabled checks, so you can set the RegExp and enable them if you need.

I propose we create:
1. Report if any type street name matches the RegExp (#123)
2. Report if any type street name does not match the RegExp (new check)
3-6. Report if Ramp/Highway/Freeway street name matches the RegExp (4 new checks)
7-10. Report if Ramp/Highway/Freeway street name does not match the RegExp (4 new checks)

So you will have 10 checks in total for different street types. Would it be OK or we missing something here?

EDIT: Regarding your regexp:
1. At the moment as a workaround you can match two RegExps in one check: "(regex1)|(regex2)"
2. You can create case-insensitive RegExp using /i flag: "/^[^şţ]+$/i"

[berestovskyy]

The changes in this version are mostly for advanced users and localization pack creators, but there are also some bug fixes:

20.03.2014 v0.9.0:
- New user-defined custom checks in Settings->Custom
- New 5 custom checks #130 - #134 for localization
- Validator now generates packages for dependant
countries

- Fixed non-editable filter option
- Fixed localization packs for Firefox
- Fixed 'Non-drivable connected to drivable' for very
long segments
- Removed 'Toolbox/WMECH: Report highlighted segments'
(now it is on by default)
- Fixed lost TODO labels on upgrade package
- Fixed 'Highlight issues on the map' menu item
- Fixed #57 for other countries (was just enabled for PL)


Those new custom checks are very powerful, but there is a learning curve Please do not hesitate to ask any questions!

Here are few examples of the new custom checks and a description of the regular expressions: MDN link

Example 1: to highlight Ramps with non-ground elevation
Template: ${type}:${elevation}
RegExp: /4:[^0]/

Example 2: Highways which do not start with the letter A
Template: ${type}:${street}
RegExp: /3:[^A]/

Note: you may add D at the beginning of the RegExp to log debug information on JS console: D/3:[^A]/

EDIT: Hey sketch, those are for you:
Example 3: streets named "U-Turn" in LA
Template: ${state}:${street}
RegExp: /Louisiana:U-Turn/

Example 4: streets with word North
Template: ${street}
RegExp: North

Once your template/RegExp are ready, you may copy them to your localization package into the checks #130 - #134, for instance:

Code: Select all

"130.enable": true,
"130.severity": "warning",
"130.title": "Highway does not start with the A",
"130.params": {
  "template": "${type}:${street}",
  "regexp": "/3:[^A]/",
},


[berestovskyy]

Street name or alternate street name ends in 'Exd' or any case variant

In the latest 0.9.0 you can use a custom check (Settings->custom):
Template: ${street}
RegExp: / exd$/i

And those names will be immediately highlighted for you.

If we create a dedicated check, I suggest we check at least few incorrect abbreviations, not just Exd.