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

[taco909]

Looks like Validator might be broken in production WME.

Edit: Looks to be working now.

[taco909]

Validator will not flag "no connection" when the elevations are different.
The change in elevation is used on the wayfinding "stub to nowhere" both to make WME route properly and to make Validator happy.

Validator USED TO flag "no inward connectivity of a driveable road" until WME was change with respect to how it handled junction vs segment information. When that happened (last July?) we lost a number of Validator features including its ability to detect RevCons. Toolbox still detects them, but for some reason Validator does not import that particular flag into its generated report.

Personally, I would not be unhappy if Validator would report on no connection at different elevations... not that it is always a problem, but I would like to have the visibility to review them.

[taco909]

There is a U-turn in this segment on node B. I've tried using

Template: ${Uturn}
RegExp: /1/

But it's not picking it up. What should I be using?

The changes made to WME last August or September "broke" the junction functionality of both Validator and Toolbox. Toolbox has "recovered" but when Validator was repaired it only picked up on unconfirmed turns.

[taco909]

A problem with a large area is there is a limit to the number of segments that can be scanned and loaded onto the results page.

Have you tried reducing your browser zoom level to display more map area?

[taco909]

I'm having trouble with a custom check. An editor has gone on a spree in my area, adding u-turns all over the place. I'm trying to locate them and remove them, so I though a custom check would be perfect for this job. Using the custom check examples it's listed as an easy one, so I'm really not sure what I'm doing wrong

Validator lost the ability to look at turn related information with one of the WME revisions last summer when turn setting information was moved from the segment properties to the junction node properties.
When this happened, we lost Validator flags for RevCons and inward/outward connectivity.

Toolbox has options to display u-turns and RevCons using icons on the map.
For normal editing, Toolbox and WMECH cover most of the lost functionality, the only problem is that the Validator Report page does not pick up flags from Toobox, only WMECH, and WMECH seems to only pick up unconfirmed turns.

[taco909]

First, let me say this is an incredibly useful tool.

Second...

Is there a reason there isn't a check for "one-way street with dead-end"? I can't think how this ever wouldn't indicate a problem of some sort. A friend believes this check used to be be present but doesn't know why it would have been removed.

"No inbound/outbound connectivity of a driveable segment"
That was one of the things we lost with the WME update last August.

And there are quite a number of situations where a dead-end one-way is desired. These are generally "stubs" that are added to force turn instructions where BC would otherwise result in no instruction.
They are not intended to be driven on, they are only there to force instructions. Making them one-way ensures that the routing server won't route someone up and down one.

Generally, such stubs are locked high, so L1/2/3 editors won't see the flag in Validator as long as they are using the default setting to not scan non-editable segments.

[taco909]

I think that the " Street name on two-way Ramp" should be removed/declassified/better explained. Sometimes it is necessary to give a name to a ramp to avoid the "detour avoiding" mechanism.
Example: This 2 segments must have the name SS16 (https://www.waze.com/editor/?env=row&lo ... ,178050565)
In order for this route to be computed properly: https://www.waze.com/livemap?lon=13.514 ... n=13.51457
(Otherwise Waze sends you to the roundabout ahead for a U turn).

The street name on the ramp itself is not a problem/flag.

I suspect that the "street name on two-way ramp" is there to call attention to the fact that there is a RAMP that is set to two-way.
In the US, this is extremely rare. The only place I've seen it is at the US/Mexico border crossing for the turn-around lanes.

But I can see the reason for it.
Standard naming convention for a ramp type would be "Exit ##: Greenbriar Rd" or "to Greenbriar Rd"
It would not be typical for both directions to generate the same instruction.
In the case of a 2-way segment joining several one-way segments, then the 2-way would be left unnamed, and it would inherit the name of the following one-way (or the adjoining highway)...

Example: Hwy 38 runs parallel to Hwy 36, but there is a crossover ramp between the two.
Leaving the crossover unnamed would produce "Exit right to Hwy 38/6" or "Turn right on Hwy 38/6, then turn left/right"
In this case, there is a name change of the roadway, so there are no detour prevention triggers that would be broken.

IMHO, given that something on the Validator report indicates something that needs to be looked at, but perhaps not always "fixed", I think the alert is a valid one, and perhaps another alert should be added for any 2-way ramp segments.


But like WMECH and TB, I would be happy to see more granular control over Validator's reported errors so that individual errors such as this could be toggled off.

[taco909]

Can Validator get updated to the latest changes to road names with cardinal directions as the primary road name - N Ave E. (for example). Previously, the method was wrapping the cardinal in quotes 'E' to prevent TTS from saying 'east'. The new method is now using a period after the letter. Validator is flagging these.

Reference point #4: https://wiki.waze.com/wiki/Abbreviation ... reviations

Thank you!

Yes yes yes.... I've been making some of these changes and I really hate to do it for fear that another editor will come along and "clear the error"
Likewise, I hate to lock Primaries at 4.

[taco909]

Crazycaveman, Thanks for the reply. I guess what I am asking is there a way to merge the HN editor info about bumping since there is someway for Validator to know if HNs or not. I don't know if the bumped/nudged HNs are called out at a separate layer

You are likely confusing Validator with the HN tool script, which is active when the HN layer is open.

I suppose it would be possible for Validator to run checks when you have the HN layer open, but without that layer open, there is no way to tell if a HN has been bumped or not.

[taco909]

Not sure if this was mentioned before.
Validator triggers an error on "Incorrect abbreviation" when the street name terminates with a period.

With the new handling of cardinals, we need to have Validator ignore this iff the last character pair is " N.", " S.", " E.", or " W."

Example: "W Avenue N." comes out properly on TTS as "West Avenue N"
This is valid, but Validator triggers on the "N."