Bill473 wrote: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.

bedo2991 wrote: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.

karlcr9911 wrote: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.

subs5 wrote: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.

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

PesachZ wrote:This has been mentioned above, but validator has not been updated yet.

You can add NE. and SW. to the list

I thought about including those as well, but I've never seen an "Avenue NE"... just things like "4518 NW" properly announced as "NorthWest"

But ya, Validator really should ignore any trailing period that does not come after a normal suffix abbreviation.

Another that I've been curious about (and correcting when I find them and have the time to go through the entire area), we keep coming up with a lot of Spanish prefixes that are not capitalized.... el Vaquero del Rio, la Madre del Sur....
I often see these not capitalized outside of mapping environments. Should these be "corrected" based on typical English structure?
Validator does flag them.

vince1612 wrote:It was actually obvious

Not really... This thread has been WAY over my head with the discussion of custom filters.

Even on this one, I don't see a "reported as:" field... is "!24,*" simply entered as a custom filter?

Validator does seem to be functioning inasmuch as it is highlighting the segments.
I'm seeing thick, bright red roads, and I'm seeing yellow highlights on segment pairs that share the same endpoints.

But I'm not seeing a highlight for unconfirmed turns.

It would be nice if an update could restore the old functionality that included Revcons, segments without entry/exits, etc...
I know Toolbox tags these, but Validator used to include them in the report, which was REALLY nice to have.

KB_Steveo wrote:

taco909 wrote:Validator does seem to be functioning inasmuch as it is highlighting the segments.
I'm seeing thick, bright red roads, and I'm seeing yellow highlights on segment pairs that share the same endpoints.

What browser are you using? There are no highlights happening in Chrome.

That was on Chrome.
I'm home and on FF now, I'll check again.

Yep... seeing the same thing here. Red and yellow, nothing for unconfirmed turns, nothing for short segments, overlaps, or disconnection.

Edit... Never mind. The yellow highlight is from Toolbox.
The red is likely WME... they had it more toned down on the new roads layer on the last revision.

Rfrsw101 wrote:I'm just wondering, is there any way for Validator to be incorporated into a tab? Instead of having it up all the time. Such as [Validator] [Drives] [Area] [Settings]... But thanks for getting it working so quickly after WME changed.

Ditto.
Validator goes away when you use the URO+ option to eliminate the editor sidebar info.