[Script] WME Validator 1.1.20 / 03.11.2016

[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]

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]

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]

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]

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:

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]

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]

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]

09.03.2014 v0.8.2:
- Auto-disable slow checks at zoom levels 0-3
- Fixed severities for some checks (Unneeded node)

- Updated #36 and #37 'Unneeded node A/B' for U-turns
- Updated 'Unneeded node A/B' for partial nodes
- NEW for AR: 'Street name matches the RegExp' (calle)
you may use localization pack to set the RegExp for
your country
- Disabled for AR #56 'Incorrect word in street name'

[berestovskyy]

validator is reporting quite a few more "overlapping segments" in my area. Was something changed?

Nothing has changed. To get the "overlapping segments" error your segments need to cross at 2º or less. Please provide few permalinks to check.

Validator reported this as "unneeded node B" in the report, but didn't identify it when I clicked the link.

Right. If you pan around with the segment selected you'll notice it goes reported as unneeded and back.

It's happening because Validator does not report "Unneeded node" if there is a 3-segment loop. But to check if there is a loop, Validator need all of those 3 binding nodes to be fully loaded (i.e. not partial). So as your upper node in the loop flaps from partially loaded state (off-screen) to fully loaded, Validator flaps the report.

I guess in this particular case we can ignore the WME "partial" flag, so I'll try to fix it.

[berestovskyy]

Please confirm that there is no need to keep the TODO at the beginnig of translated string.
once translation is done how will it be distribute?

Sure, it's just a marker for your convenience, so please delete those TODO prefixes. Just untranslated lines will be marked with TODO, so I hope it will be easier for you to update the package in the feature.

If you keep those .en lines, Validator will compare those lines with the built-in lines and mark your translation with TODO prefix if your .en line is different.

Those localization packages are designed for the following workflow:
1. You generate the package using the Wizard. All of your previous translations are preserved.
The generated package is a Greasemonkey/Tampermonkey script ready for installation.

2. You translate TODO lines and install the script using Tampermonkey/Greasemonkey along with Validator. Validator will pick up your translations immediately (see JS console for the lines "found localization pack: France")
So you always have two scripts installed: Validator itself and your Validator for France.

3. Say, a new version of Validator is released with few new checks. Having those two scripts active, you just click Settings->About->Wizard and regenerate the package, translate the difference and reinstall.

Regarding the distribution. There are two ways:
1. Your local community maintain/distribute the package. I can put the link to your local thread, i.e. "Download French translations here" or whatever. Also on your request I can import just enabled/disabled checks and options (no translations).

2. Alternatively, I can import the whole package back into the Validator on your request.

Both ways have cons and pros. I would prefer the 1st one, but it's up to you.

Any suggestions are welcome!