[Script] WME Validator 2020.10.25 (PLACES BETA)

[AlanOfTheBerg]

This has been well documented in a few different forum discussions, which the Validator author provided links to earlier in this thread.

Thanks Alan, that's all I needed to know. I don't always have the time to read all of the threads and posts, that's why I started out with the comment that it might have been brought up before.

Discovered I believe I was wrong. It got sent to me via PM. He provided two links to threads about 2-part/3-part loops.

[AlanOfTheBerg]

There were comments this was a known issue with Cartouche, but not necessarily the current WME.

Today I sent a message to the Waze team on that specific issue. I will report back what they say relative to this issue. If anyone has any current routing issues they know about or can find any forum threads showing this is still a problem then let us know and we can add it to the Wiki best practices.

There are definitely threads about issues with routing related to segments which shared the same endpoints. And this has nothing to do with Cartouche, as it doesn't do routing, so why is that even relevant to the discussion? The issue with the routing server has existed since the days of Cartouche. I doubt Waze will officially have much to say about it because they've never properly responded to the threads displaying the issue.

Don't forget this is also the reason why WME does not allow the starting junction to split a segment if the end junction is on the same segment. It's been built into WME since the very beginning to dissuade this type of loop from being created.

Related threads:
https://www.waze.com/forum/viewtopic.php?f=8&t=70559
https://www.waze.com/forum/viewtopic.php?f=8&t=69415

[AlanOfTheBerg]

...For now it seems like lower case names would be the exception, and 'la' and 'el' should not be added to the exception list. I think the summary from the other forum thread was "match the case of the road sign"

I agree. Since most signs are uppercase, in Waze we would typically switch this to initial caps.

[AlanOfTheBerg]

Don't know about the Int'l server, but having two one-ways that connect the same two junctions has caused problems in my area. If the origin or destination is on one of the street waze will occasionally start or stop the route on the other. This has been solved by adding a extra junction on one of the segments.

Validator should already be detecting two segments sharing end node locations, regardless of street direction.

[AlanOfTheBerg]

If you look here, there's a pair of segments, and Validator considers the node between them to be unneeded, however the top segment has time-based restrictions (there's a gate there that's closed at night) but the lower segment has no such restriction.

I don't get this. Why would you ever traverse the lower segment just to turn around? Why not have a single segment with the restriction? It doesn't go anywhere else, so regardless of whether it is one or two segments, the routing effect is identical. Or else I'm not getting it...

If Waze thinks the destination is closer to the segment with restrictions than any other segment, it will override the segment restrictions. This is just like any turn restriction.

The only thing this segment restriction does is affect travel along the whole segment, so having two parts is unnecessary.

[AlanOfTheBerg]

If Waze thinks the destination is closer to the segment with restrictions than any other segment, it will override the segment restrictions. This is just like any turn restriction.

Are you sure? In tests I did a little while ago, Waze acted as if the restricted roads didn't exist at all...
(behaviour may have changed since, without warning, as it often does)

Things change all the time, so I very well could be wrong. In fact, that'd be great in this case!

[AlanOfTheBerg]

Here's another example.

Works exactly as if that segment were set as Private Rd. So, I guess it's one way or the other...

[AlanOfTheBerg]

Has there been a change made to the way that the Validator handles roads marked with (CONST ZN)?

The blue Note reminder was added because there are often old construction zones for which the segment named never were changed back. I found two yesterday in different areas which I wouldn't have found before without this feature.

[AlanOfTheBerg]

The blue Note reminder was added because there are often old construction zones for which the segment named never were changed back. I found two yesterday in different areas which I wouldn't have found before without this feature.

This was lit up in red complaining about no inward/outward connectivity, which really kinda made it stand out. Blue would have been less annoying.

Example.

Ah! So, it wasn't red because of CONST ZN, but because of the connectivity issue.

Perhaps there should be an exception for the inward connectivity for segments which are marked CONST ZN then. That way, if happened upon or in a scan, they are "caught" and user alerted for the CONST ZN with a BlueNote and not the more serious RedNote.

[AlanOfTheBerg]

I don't think "junction at one end must have a freeway/highway/ramp segment" is true based on my knowledge.

Unless someone can identify the problem (which then can be added to the Wiki), it is certainly possible for one (Primary) Street to pass over another (Primary) Street and have a connector between them marked as a Ramp. In that situation a Ramp is fully legitimate, but not required.

Kent, I think the vast majority of situations will have a ramp connecting to a mH, MH or Fwy. However, you are correct, and I have these in my area, where primary streets cross over and there are ramps used to connect them. I believe these are legitimate use of ramps as well. "Grade-separated" doesn't exclude Primary Street type.