More nodes are not "excessive", they're just more nodes. Staff has said that adding nodes is not a problem. And, well, nodes are needed to make it look right.

Caveat: we should be careful about median U turns, e.g., more nodes should not be added for bridges over depressed freeways that are at the same level physically as the frontage road. Also, if the node would be added within a few dozen feet of the end of a segment anyway (especially ramps), then adding the node in that case would be needlessly complex. But we're talking on the order of tens of feet, not blocks.

I came to report this problem with Creating and Editing Road Segments ► Road elevation, but saw that @subs5 had already reported it months ago. Any chance we can get it updated to match the current guidance?

Since @subs5 didn't have a chance yet to propose a first draft for correction, I will:

Current Elevation Wiki wrote:3. Elevation -5 is used for non-drivable roads to help ensure that the routing engine does not try to connect or route drivers from roads onto non-roads by mistake. It acts to prevent false system reporting that the roads should be connected.

Suggested Changes wrote:3. You may find elevation set to -5 on non-drivable roads, as that was the former guidance due to issues in the routing server. Those issues have since been corrected, so non-drivable roads should now follow the same elevation guidance as any other road segment.

Thanks!

CBenson wrote:I'm not sure that nodes added for elevation changes really take up any additional computing power for route generation.

I agree. In addition, it was discussed in the Northwest USA Google Hangout about adopting Australia's guidance regarding elevations to the northwest, and it specifically suggests doing exactly this:

Elevation - bringing the Seagull to Australia (Wiki) wrote:Well, that's not surprising either, but here comes the big one (at least for the guys who have given some thought on routing issues):

• In many cases we will need to split segments into two or more segments to correctly mark only the right parts of the road as a bridge or a tunnel. (again, this is important for the map’s fidelity and as cues for drivers)

If you can't believe we are now introducing extra junction nodes (for we have been eager to avoid them in the past), just read the para again, because definitely yes, we are doing it from now on. Waze have looked into possible impacts on routing calculation and routed them out, they choose "to stick to an accurate representation of the map with tight marking of bridges (level greater than 0) and tunnels (level lower than 0)".

(emphasis added)

So IMHO, line item #4 should be stricken from the draft.

dmcrandall wrote:Or modified to better explain...along with an example image.

The main point of #4 deals with the adding of nodes (presumed to be excessive) for the purpose of elevation. If that line item remains, then it seems that we're not wanting to move this direction with elevation for some reason. If it's not due to computing power or the routing server, etc., then what is it? If we would be moving toward creating nodes for elevation, then why would Item #4 need to remain?

The part dealing with the segments shouldn't be too long, etc., would be a moot point if the segments will only be elevated for the length necessary (as opposed to the current arrangement, where it's elevated from one junction to another), as presumably, those long segments would then be Ground segments. At that point, too-long segments would be covered under another topic, not Elevations.

Sorry for the delay, my suggested change is:

The Road Elevation should be changed where one road passes over another. By default, the Elevation of a segment is Ground (zero). When two segments overlap but do not actually connect in the real world, the value of Elevation for each segment must be different. This ensures that the Waze problem detection system doesn't flag the spot where two segments overlap as a location where a junction might be needed.
The visual representation of the relative Road Elevation is different when viewed in the Waze Map Editor (WME) and the Client application.
1. The Client App displays segment elevation based on the road type only, meaning Freeways are always on top, Major Highways are next, followed by Minor Highways, Ramps next, Primary Streets below all those, and finally Streets are at the bottom. This is the same order seen when setting the road type in the editor.
2. The WME uses the Road Elevation setting to display the relative elevation of the road. It displays the road with the highest "elevation" number at the top of the visual stack and works its way down as would be expected.
Although the client application does not benefit from the Road Elevation setting, it is recommended to set the Road Elevation relative to the physical mapping in the real world to enable possible future Client application updates to show the same visual representation as the WME.
3. Please refer to your State's Wiki page for local guidance since there are some variations. The two main ones tend to be:
a) Lowest Road that sees the sky is "ground" and then raise the elevation for the subsequent road segments up as required. Roads that go under buildings or a body of water would be tunnels and have negative elevation (and marked as tunnel appropriately)
b) Freeways are always elevation +1. Roads are over them are mapped with higher elevations. Other lower FC road segments follow a) above.
4. Excessive nodes should be avoided just for elevation since it takes up computing power for route generation but map making is part art and part science. Having one section that is elevated to level one that crosses two parallel roads is ok instead of having a small bridge at elevation +1 then a ground for a few blocks and then another small bridge; that should just be one elevation +1 segment. Whereas having a Freeway segment that is miles long should not be Elevation +2 since that often causes problems. Prudence to check the entire length of the segment is required since the built in validation/error checker may not catch problems that are off the screen.
5. At the end of 2015, WME changed the way non-driveable roads are treated. Now non-drivable roads should follow the guidance above. You may encounter Elevation -5 is used for older non-drivable roads; this was to help ensure that the routing engine did not try to connect or route drivers from roads onto non-roads by mistake. This is no longer required. Please follow the road segment elevation guidance for non-driveable roads.

Ok, based on above comments. I have left in #4 since I have not received guidance as to whether junctions should be added. For the routing issue problems I have seen that part of the problem is too many junctions so if anyone has more information please PM me. If people want pictures we can work to that after the wording is agreed to:

The Road Elevation should be changed where one road passes over another. By default, the Elevation of a segment is Ground (zero). When two segments overlap but do not actually connect in the real world, the value of Elevation for each segment must be different. This ensures that the Waze problem detection system doesn't flag the spot where two segments overlap as a location where a junction might be needed.

The visual representation of the relative Road Elevation is different when viewed in the Waze Map Editor (WME) and the Client application.

1. The Client App displays segment elevation based on the road type only, meaning Freeways are always on top, Major Highways are next, followed by Minor Highways, Ramps next, Primary Streets below all those, and finally Streets are at the bottom. This is the same order seen when setting the road type in the editor.

2. The WME uses the Road Elevation setting to display the relative elevation of the road. It displays the road with the highest "elevation" number at the top of the visual stack and works its way down as would be expected.

Although the client application does not currently benefit from the Road Elevation setting, it is recommended to set the Road Elevation relative to the physical mapping in the real world to enable possible future Client application updates to show the same visual representation as the WME.

3. Please refer to your State's Wiki page for local guidance since there are some occasional variations. The main guidance is: Lowest Road that sees the sky is "ground" and then raise the elevation for the subsequent road segments up as required. Roads that go under buildings or a body of water would be tunnels and have negative elevation (and marked as tunnel appropriately). This is sometimes called the seagull approach.

4. Excessive nodes should be avoided just for elevation since it takes up computing power for route generation but map making is part art and part science. Having one section that is elevated to level one that crosses two parallel roads is ok instead of having a small bridge at elevation +1 then a ground for a few blocks and then another small bridge; that should just be one elevation +1 segment. Whereas having a Freeway segment that is miles long should not be Elevation +2 since that often causes problems. Prudence to check the entire length of the segment is required since the built in validation/error checker may not catch problems that are off the screen.
5. At the end of 2015, WME changed the way non-driveable roads are treated. Now non-drivable roads should follow the guidance above. You may encounter Elevation -5 is used for older non-drivable roads; this was to help ensure that the routing engine did not try to connect or route drivers from roads onto non-roads by mistake. This is no longer required. Please follow the road segment elevation guidance for non-driveable roads.

Word that I have heard is that Staff says that adding nodes along a route has negligible impact, but if a route is close to failing, it can push it over the edge.
I know that they have made some improvements lately to the long distance routing but we did have a lot of problems with routes over 500 miles over the holiday season in the Mid-Atlantic Region and they have been submitted to the form for sending to Staff.

Sorry snow storm took away a few days. Here it is for review in my wiki page. Just started it so any suggestions on how to run the wiki page are welcome too (via PM).


Well based on this forum post in SM GHO, bringing seagull to Australia; looks like the work on the above is all for naught.

This change is proposed to
https://wiki.waze.com/wiki/Creating_and ... d_segments. I think subs5 is correct.

This section needs to come in line with the recommendations for the different road types.

Subs5 -- thanks for finding this. Can you propose a first draft of simple new wording for that?

Thanks!