Two regions already fully support and practice the concept of “True Elevation” (TE). They are the SER and SCR. Thanks goes to the leadership over in the SER for putting together the framework for the TE guidelines. In the SCR, we used this framework while making wordsmith changes to our benefit (thanks Sketch, bossbryan, and others), while keeping in mind this would be the same guidance presented for national inclusion. That being said, I hope what we have written for the TE is in a state to be accepted by all regions and included in the USA page.
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.
Yes. This was discussed, in detail, in the SCR. Sketch was the leading proponent of removing the requirement. After long deliberation (see what I did there Sketch?), we all agreed with the wording on the definition of a “bridge” coupled with some bullet points eliminated the need for a distance. It is believed that any span that qualifies under the definition of a “bridge” is deserving of the elevation change.
Here, earthen construction is anything that has the roadway supported by earth. These are typically box culverts, round culverts, etc. Anything span wider than 20ft, by civil engineer definition, is considered a “bridge”. Anything less than 20 ft is considered a culvert and not a bridge.
Good idea. That will take some work as LiveMap has been spotty on updates lately. It’s hard to get “before and after” pics of areas as LiveMap may or may not update when you want it to.
Looks like a great start. I’ll be interested to follow along and see how this is implemented. I know in some dense urban areas, additional considerations have to be made along freeways to prevent poor data collection.
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/West_Virginia#True_Elevation.I imagine the original wording (before my time as SM) may have been derived from one of the regions mentioned above.
It’s great to make the map more accurate, but because of Waze’s design I believe we need to be very careful with this. Adding junction nodes under certain circumstances degrades routing performance! In dense urban areas especially, adding junction nodes in the wrong places will compromise timing measurements and cause suboptimal routes.
Below is an image of a bridge over an Interstate that has been “cut” with extra junction nodes to provide maximum display fidelity (eventually, we hope, anyway). The westbound timing measurements have been compromised as a result.
Notice the very long left-turn lane/pocket in the westbound direction, extending all the way back to the yellow arrow at far right. If left-turning traffic backs up to the yellow arrow, it will have backed up over both junction nodes that were added to delineate the bridge (red arrows).
Waze, as currently implemented, can only measure turning traffic separately from straight-through traffic over the final segment leading to the turn. Thus, additional junction nodes located in turn pockets before the turn can cause Waze to conflate turn delays and straight delays together in one big average. Wazers waiting to turn will make the straight-thru delay appear longer than it really is, and Wazers driving straight thru will make the turn delay appear shorter than it really is (typically).
In this particular case, the junction nodes are back far enough that the degradation will only happen when traffic is quite heavy and the left-turn backups extend over the bridge. But that’s exactly when we want Waze operating at its best.
I like accurate maps as much as anybody, but additional junction nodes are not always “free”. If the US community goes in this direction, the guidance must be clear enough to prevent cases like this.
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.
I like the 200 foot rule used in the speed limit page. I recommend following that here, so under implementation I would recommend:
If your new node would be placed within a few dozen [h]200[/h] feet of an existing node, you can either use the existing node as one end of the bridge, or, if desired, add the node for the elevation change and then add a junction box. If elevations are displayed in the app in any way similar to how they are displayed now in Live Map, 200 more feet of positive elevation is barely noticeable.
The 200 foot rule is used in the current versions of True Elevation in SER and WV (that I know of). There were discussions in Discord about changing this to what is in the current draft, which also matches the SCR version of TE. I think we should keep the 200 foot rule of thumb. It also helps that it is familiar to editors from the SL page.
The 200-foot rule would not prohibit the junction nodes in the example I posted above. Distance from the intersection node to the nearer bridge “cut” junction node is 272 ft; total distance to the farther “cut” node is 430 ft. And the beginning of the turn pocket is further back than that.
The congested urban areas I’m familiar with can have an awful lot of long turn pockets and separately-timed stoplights. I don’t believe a 200-foot limit would come near to eliminating timing degradation.
I suppose a separate question is whether the editing community is OK with timing degradation if it (eventually, we hope) buys us better display fidelity…?
Where it gets tricky is if we say we are OK with “some” timing degradation but “not a lot” because it’s impossible to quantify beyond the fact it’s happening (by design). I have seen URs in a situation with a long turn pocket and a very short left-turn light that only lets a few cars through at a time; a masking junction node in that circumstance massacred Waze routing performance. But usually if Waze misjudges route performance by a minute or two few drivers will probably notice.
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 :mrgreen:
I was going to quote everyone here, lol. But it would have made a post longer than the New York Times. Therefor I’ll just wing it.
The example DwarfLord showed can be overcome by a junction box. It is discussed in the implementation section:
I like the 200ft rule, but think it could be shorter. However, I don’t think we should make any assumptions until we know how the app will actually implement elevations. This draft, along with it’s current inclusion by SER and SCR, was developed with the mindset the app will mimic how the livemap displays elevations at this time.
I don’t think this will gain much traction until we actually get more details on when and how (if at all) the elevations will be displayed in the app. Until then, if your region wants to use this as a template for your own regional or local guidance, feel free. I’d be more than happy to discuss with you why we wrote it the way we did.
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).
I completely agree. With the backyard baseball going on, there isn’t a lot we can do as far as trying to establish a national, or really even regional, guidance on this. I created this thread with the mindset the app was going to mimic how the livemap displays things now, and even that change was on the horizon (sooner than later). But with the information passed along to me from other champs, I feel this thread was a bit premature. Thank you, @JustinS83 for sharing information that has moved this thread into a dormant stage.
To address your issue DwarfLord, we added the caveat of a junction box when any junction is added within a turn pocket (very short distance of an existing junction node). However, how often would this occur? Would the increase of JB’s all over the map to collect more reliable speed data through multiple JN’s create a better (or worse) routing experience? I think ultimately we will need to figure out a number that we would not want to add junction nodes for merely elevation changes. As you stated, this is very hard thing to put into guidance as it is fluid. Hopefully once we see how the app will handle elevations, we can more accurately setup a guidance for it.
I agree with the sentiment that more needs to be known about how / when / whether elevation will be incorporated into the client app and how elevating segments enhances the consumer driving experience. The trade-offs that DwarfLord pointed out will need to be weighed against these benefits.
I can see how major bridges having special visual reinforcement would be cool and reassuring to drivers, and in fact some landmark-style bridges (such as the Golden Gate Bridge) have area places for this purpose today. The initial draft wiki page doesn’t distinguish between major waterways such as the San Francisco Bay and a small creek or culvert that is not memorable and barely noticeable. Knowing how the client would visualize the elevation is needed to have an informed debate on how widespread true elevation should be used.
Given a belief that a change is likely we could in the meantime encourage editors to find and fix incorrectly elevated segments (under today’s rules). There are quite a lot of those, and given the lack of elevation-awareness in the app, many of us have not been prioritizing finding/fixing those unless other nearby edits are in play.
Agreed. Until we know more, there isn’t much we can do. If it ends up being like it is in LM, then there is a negative impact to having improperly elevated or submersed segments. Especially over a great distance (entire segment as opposed to just the actual section needed).
It does:
The final sentence is key. Earthen construction = culvert. Box culvert, cylindrical culvert, etc. These usually have earthen construction supporting the roadway / around the culvert.
Completely agree here too. As I have panned around the map, there are areas that don’t conform to the current guidance. However, it isn’t a crucial issue.
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.
I wanted to through my support behind the 200-foot minimum segment. We use this standard in Illinois (https://wazeopedia.waze.com/wiki/USA/Illinois#True_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).
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:
