Kartografer wrote:Well, to be fair, DB's draft did mention junction boxes.

True. But, given the number of bridges and cuts that might be necessary, this could mean a lot of junction boxes. In that sense there's some similarity to the question of whether the community should embrace junction boxes around every H intersection of a divided highway so as to provide "U-turn" instructions instead of a "left-left". That perspective at least improves routing instructions, but what we're buying here is increased hope that the display may render with better fidelity some day.

Again, I'm all for better display rendering, should Waze ever pursue that. My hope here is only that our guidance is up front about the serious tradeoffs and clear about how the community prefers to deal with them.

I should probably shut up here since I'm a bit in left field and perhaps all sorts of things are happening and being discussed about which I'm clueless. Maybe Waze is just about to release display improvements and fix their junction-node system to handle turns that might be multiple segments away -- making all my concerns moot -- but nobody can say so publicly. Wouldn't be the first time

So, I've been informed that active discussions have been going on regarding this topic and that some kind of change may be coming that could affect the conversation. So I'm not sure how much good this wiki thread can accomplish while things behind the scenes are in such flux....

For the record, anyway...

At present there are two separate kinds of junction-node issues and I'm concerned we're getting them mixed up.

The first issue has to do with the gradual degradation in Waze's timing measurements as segments get shorter and shorter, combined with what may be (?) a concern about route generation and management efficiency as the number of junction nodes on a route increases. The proposed guidance does address this issue, which is great.

But the second issue has to do with timing degradation specifically on the approach to intersections with different turn timing for straight vs. turn. In certain cases, such as the example I posted earlier, a junction node beyond a few dozen feet or even beyond 200 feet (!) can degrade routing.

Converting this concern into guidance is hard. But, because the presence of turn pockets often (though not always) indicates an upcoming intersection with different straight/turn timing, one could make a simple rule to "try as hard as possible not to add a junction node along a section of road that includes a turn pocket, regardless of distance before the intersection; or if doing so is unavoidable, add a junction box to preserve accurate timing". The language could be improved but that's the gist.

Anyway, since things are apparently changing underneath this discussion it may be safest to wait for additional clarity before proceeding (which I believe the OP is also recommending).

A simple, consistent number makes for clear guidance and repeatable editing practice. What worries me is that the underlying problem has so much variability. In some cases, adding a new junction node only 100' away is not a big deal; in others, even 400' may not be enough.

The problem is involved enough, it may be best to do it justice in another article, or in a new article, and then refer to it in discussions of True Elevation (or Speed Limits, or Railroad Junctioning, etc.). To that end I've started a new thread here:

viewtopic.php?f=1636&t=261298

I wanted to through my support behind the 200-foot minimum segment. We use this standard in Illinois (https://wazeopedia.waze.com/wiki/USA/Il ... _Elevation). The rationale was to avoid introducing yet another minimum length standard. Editors are already familiar with the 200' minimum for speed limits. While there may be some display exaggeration, the combine benefits of improved data, common standard, and simplicity outweigh the minor visual distortion.

On the other (non-simplistic) side, Illinois:

• Allows addition of TE segments for culverts when they would allow for better routing during flooding or replacement.
• Includes specific provisions for multi-deck subterranean roadways. We included this specifically due to to the multi-level road system under Chicago.
• Specifies the neither the elevated segment nor non-elevated segments created as the result of cuts be less then 200' in length (but with more words).

I don't recall a national decision being made.

Looks good from IMHO. I would support this nationally.

Was there discussion on how small the bridge can be to get a +1? Meaning for a stretch of road over a simple 10 ft wide canal, do we bother with that? If not we should add another definition for what not to elevate.

On the example links, I think it would help to create a small table of visual images with both the WME and Live Map to give a quick visual without having to go to all the links. That way the reader can find the one most closely associated with their situation.

I think we are on the right track and I fully support DwarfLord's concerns.

IMHO, the most accurate routing should be our top priority over visualization. I never hear anyone complain they can't tell if the road is a bridge above or below another, but I constantly hear complaints that Waze took a route that turned out longer than reported.

Bubbling this back to the top. I noticed some of the state pages are using some of this content. Did we come to any agreements countrywide on use of this feature and forget to come back to this entry? I didn't see anything covered in the forums.

We also practice True Elevation in West Virginia, except for Freeways and Ramps. Otherwise, our wiki guidance seems very similar to what has been proposed: https://wazeopedia.waze.com/wiki/USA/We ... _Elevation.I imagine the original wording (before my time as SM) may have been derived from one of the regions mentioned above.

I believe that case that DwarfLord brought up would fall under the "use of common sense is paramount" clause and I wouldn't implement it there. It certainly wouldn't hurt to add a couple examples like this of when not to use TE.