sketch wrote:

kentsmith9 wrote:Validator and Toolbox both believe this segment should be straightened, but in my opinion is pulls the road a little too far off the actual road since it curves. It seems like it might be a little too aggressive in what they are both considering is a straight enough line.

The Validator-Toolbox highlights are pulled straight from Toolbox -- in other words, Validator is just reporting what Toolbox reports in its reports -- so only Toolbox's selection criteria will affect this (but I agree that Toolbox is too aggressive in this function).

Thanks. I will move my comment to that thread.

krikketdoug wrote:

sketch wrote: I'm not sure how much of the rules support this, exactly. Railroads are to be set at -5, certainly, as are Walking Trails (if mapped at all), I believe, but a Pedestrian Boardwalk shouldn't always, necessarily. I think a lot of these rules are in flux.

I could have sworn I saw somewhere on the Wiki that all non-drivable roads should be -5 (except airline runways, which should be a 9) but that might just be a local agreement.

I could not find that detail in the primary Wiki page on Runways:

Main Wiki Page on Runways wrote:For aircraft at airports. Where a street also serves as a taxiway (such as in a community with through-the-fence access) map the street as a street. No drivable road should connect to or cross over any runway. A road may cross under a runway.
Each runway may be mapped as a single segment for identification purposes and locked to prevent lower ranking editors from attaching a road to the runway. Do not form junctions where runways cross. Name each runway using the FAA airport identifier, the word runway, and the runway designations with the lower number first (e.g., "KSMF Runway 16R-34L".)

Before we do that, let's be sure we understand the turn issue. I saw a bunch of those errors flagged in CA. They were mostly at Bowtie intersections for the U-turns. I told Jemay I did not want to go through 500 bowties to tweak the angles if the route will still allow a car to do a U-turn there. I know a road would not generally allow a car to turn such a harsh angle, but when you are at a stop and doing a U-turn in an intersection you are going 3 miles per hour and you can do any angle.

Besides most of the bowtie intersections will be replaced by junction boxes (soon ) so we should not be touching those intersections twice if not necessary.

Therefore we need to find out if those flagged issues were problems under general conditions vs. the routing server will NOT route through that harsh an angle.

ditchi56 wrote:Validator complains about this, coming up with errors 118, 119 & 78.

I just created a similar setup in my test area and found the following:

1. 118 and 119 seem resolvable by having the 2 degrees of separation recommended. I don't see why you have them actually overlapping if you then have a massive bump in the middle that will clearly be seen in the client. I have the two roads parallel each other by a small gap and it seems fine.

2. 78 is there for routing. Just split the toll segment and you: a) fix any routing issue if you start in one of those two segments, and b) solve the error message.

ditchi56 wrote:1. The two segments must start and end overlapping perfectly. If you have the 2 degrees of separation, you risk Waze generating unwanted "keep left" / "keep right" instructions.

I believe if both road names are the same, you will NOT get any instructions. I believe this has been tested many times and is the subject of this page on turn instructions. We have reviewed this logic and now Waze is confirming it is accurate.

ditchi56 wrote:There is no massive bump in the middle, the central separation is kept small so that it is only visible in WME at high zoom, and not at all noticeable in the client.

Two parallel roads with a small gap would appear as two roads in the client, which would be an inappropriate rendering of a single road on the ground.

My experience is that roads closer than about 2 meters apart cannot be visually separated in the client enabling two parallel segments to appear as one.

ditchi56 wrote:2. This solution has been running for six months now with no reported routing problems. I'm not sure whether this is because the segments are so short that Waze can start routing from the end rather than the middle without anyone noticing, or whether it is because it doesn't matter which segment it starts from. Either way, there is no routing issue here to resolve.

The routing problem for same two nodes for two segments is not something that would affect through routing in this example. It would only be if you started your routing on one of these two segments. Therefore the chance of a problem is extremely low if you don't add a node in the middle of one of them, but there is no down side to adding the node so why not do it for consistency in the logic?

ditchi56 wrote:Please refer to the Waze Wiki if you require further information.

Thanks for pointing out that link. I totally forgot Ianhouse created that page last November, but never linked it to any pages.

It appears that page should be reviewed with our current knowledge to update it and improve those recommendations. An entry in the Wiki forum thread already exists for this page. I will resurrect it to review it with our updated understanding.

CBenson wrote:

kentsmith9 wrote:

ditchi56 wrote:1. The two segments must start and end overlapping perfectly. If you have the 2 degrees of separation, you risk Waze generating unwanted "keep left" / "keep right" instructions.

I believe if both road names are the same, you will NOT get any instructions. I believe this has been tested many times and is the subject of this page on turn instructions. We have reviewed this logic and now Waze is confirming it is accurate.

I think that if both road names are the same, both road types are the same and the road names are the same as the segment before the split you should not get any instructions. Merely making the names the same shouldn't necessarily eliminate the instructions. (However, for this application the road names and types should be the same for all the segments, no?) My understanding is that overlapping the segments will eliminate the instructions regardless of the road types or names.

I recommend we move this discussion to the Wiki thread to keep this thread on the Validator.

I generally don't use the reports, but the on-map visuals are working fine for me in NA.

Yes the extra nodes are required. There is a different thread that confirmed that requirement and then made it into the Wiki.

For the Toolbox, there was a time early on when the Sweep function would remove a node in a few loops and then the Fix Loop function would add it back in. I tried to give examples a few weeks ago and some improvements were made to those algorithms. I have not noticed any recent Break-Fix-Break conditions like I was seeing in the past.

I have not seen a time when Validator disagreed with the Toolbox operation when it left the node in a loop.

As for editors manually removing the extra nodes, there is no stopping that except for education (and possibly rank locks).

Jay91150 wrote:Awesome, thanks. Sorry for not finding it in my search.

I also had not see this script before you asked about it. I have now added it to the Wiki on the tool page.

And I just ran into an area where after I Q a junction, it get a save error. Noting I can do will let me Q or QW the junction in the last 30 minutes, but it was working fine up until that point.

This is the location if anyone else wants to try it on their system.