You can create draft text, we can make it fit the wiki syntax for you. We always need more people to help with the wiki. You don't have to be an expert.

Sent from Android using Tapatalk

Fredo-p wrote:What also needs to be mentioned is how to break up a bridge segment. Where do you put the nodes?

IMO, I belive the bridge itself should be when the elevation actually changes. This would give a true representation of the road. Not just the abutment.

So, instead of placing the nodes to break up the road like this:

https://lh3.googleusercontent.com/-SW0u ... 252001.jpg

I would do it like this:

https://lh3.googleusercontent.com/-CVDQ ... 252002.jpg

If the overpass/bridge is in between two junctions, then leave the segment as is. No need to do anything else.
Example:
https://lh6.googleusercontent.com/-LUAo ... xample.jpg

This was discussed in the "seagull" page referenced in the OP, and listed as a direct quote from the devs. There it says the bridge is the part of road a seagull could fly under. Meaning only the portion with Free air below it, not the portion on raised ground.

Edit IMHO if the difference between where the bridge starts, and an existing junction is less than several meters, I'd leave it as is.
Sent from Android using Tapatalk

US champs have been advocating this method since hearing it from staff at our meetup albeit not with the seagull analogy. The rule has been the same though, segments on solid surface with no open air beneath them were set to ground even if they were depressed or elevated.

Sent from Android using Tapatalk

Fredo-p wrote:Tunnel or bridge (+1)? That is a very narrow underpass.
https://lh3.googleusercontent.com/-mANL ... bridge.jpg

https://www.waze.com/editor/?env=usa&lo ... s=50673140

It is very narrow, but if you asked me if still call it an overpass, not a tunnel. The road goes up and over, the other road does not go down and under. IMHO +1

Sent from Android using Tapatalk

Fredo-p wrote:So, based on the article the only way a road would ever get -1 or lower is if it actually goes underground (ie a tunnel)?

Precisely (or maybe just maybe under a building, or series of buildings)

Sent from Android using Tapatalk

It's not that creates must be bring, it's that a (depressed) roadbed under open sky on solid ground (most interstates/fwy in the US) should be ground, a Fwy which is elevated over free air space (not just a raised roadbed) should have a + elevation. That is precisely what waze has asked for.

Waze made no mention to my knowledge of aligning certain elevations with road types, the elevation should be set based on physical parameters not road type. A freeway on a bridge is set to +, a freeway tunnel is set to -.
Therefore this over/under pass should be treated like any other regardless of road type.

Whichever road changes grade to accommodate the other should be adjusted away from ground accordingly IMHO.

Sent from Android using Tapatalk

Perhaps because staff asked us not to set above ground segment to negative elevations?? And because staff want the bridges to be represented on the map?

Sent from Android using Tapatalk

I want to clear up so grave misinformation mentioned in the last few posts. This is not as doomsday as you're all making it out to be.

dmcrandall wrote:....
Waze, along with some Champs, have acknowledged that there is a magic number of nodes, or breaks, in a segment that will result in a data overflow during a search. What is that number? Nobody is talking (maybe they don't actually know what the limit is). Dovid briefly mentioned it in a previous post on this thread.

Yes there is such a number, nobody is talking because A) it is proprietary and confidential so no champ is allowed to disclose it, and B) it is a moving target that can be changed frequently as necessity dictates by the Devs responsible for keeping the system running, there staff are not comfortable releasing a number. What I can quote from staff is that "the limit is so high that it should not be possible to reach it under normal conditions. It is a sanity check/fail safe of sorts for the server to break an endless loop of other such issues. It is not the reason many routes fail". IIRC though I can't be certain they also said that it is very rare the this node limit is the cause of a route failure.

dmcrandall wrote:Why would we chop up the primary road types that Waze uses for longer distance navigation planning, just to make it look "pretty" or to make it conform to imagery? Every node creates one more segment with data that Waze needs to process while figuring out a route. Each node introduces a variable (time across the segment, traffic delays, etc) to the routing server. By cutting up Freeway (and MH) segments just because a lower class road goes under it, we are losing the historic data in that segment of road. Without the data, Waze can't accurately determine an ETA, and will discard a perfectly good route because of it.

Devs confirmed, in person at the meetup, that Waze will default to a longer route with a firmer ETA than a shorter one with an ETA that may vary based on traffic/signals/no historic data/etc.

What the "Seagull" approach, taken to the extreme of hacking up major road type segments, does is create a map full of new segments with no historic data. You're basically wiping the map clean, all because the major road segment happens to pass "over and under other roads that may have been at the same spot for a hundred years before the freeway was built."

That is the definition of "unneeded and pointless."

This seems to imply that adding a nice to segment by cutting an existing segment in two is tantamount to deleting the segment and drawing two new ones. This couldn't be farther from the truth. The reason we encourage recycling Segments, and cutting 2-way segments to make two 1-way segments when dividing a road, is because even when cut, the segments still retain their historical speed data on both resulting pieces. If your freeway segment has a recoded average speed of 50mph, and you cut it, the new two pieces will both have and average speed of 50mph as well. The same holds true when you stretch or shorten a segment, the segments historical speeds are adjusted to proportionally match the new length.

In regards to nodes being penalized lets remember that speed data is recorded in two sets; 1) time to cross a segment from end to end, and 2) time to transition from this segment to (each of) the adjacent segments.

Adding a new node does add a new transition to monitor, but because that transition only has one option (only 2 segments connected) the transition time should always 0, or very close to it. The default transition time in this case can be assumed to also be 0, or very close to it. Not to mention that on any high priority road, there should be enough traffic daily to collect enough data so it doesn't even use the default almost immediately (within the first day or so), the long term effect of a two segment node on a high priority road is negligible.

So to put this in perspective of the example adding an overpass to a freeway.
Previously the freeway was one long segment, with a 65mph avg cross time, and no transition times in the middle. Let's assume a 10 second transition to continue straight as you pass the exit.
Now you have 3 segments, each with an average cross time of 65mph, the last segment still retains the 10 second transition time as you pass the exit. Although there are now two additional transitions being assessed, those transition times should be 0 or very close to it. Said differently those 2 new nodes should not have any penalty associated with them since they each connect only two segments.
In conclusion the total calculated time to traverse this stretch of freeway is not increased by the bridging over the other road.

Sent from Android using Tapatalk

dmcrandall wrote:

PesachZ wrote:...Not to mention that on any high priority road, there should be enough traffic daily to collect enough data so it doesn't even use the default almost immediately (within the first day or so), the long term effect of a two segment node on a high priority road is negligible...

Come west. We'll show you major roadways with zero cell coverage for dozens of miles. It takes longer than a day or two to collect the data for the new segments.

Remember these are not new segments, they are pieces of a bigger segment, therefore they already have data, and don't need to acquire new data. Only the traditions needs to be learned, but even if they are never learned, the default transition between at a node with only two segments is 0 seconds or very close to it. So even if no new data is ever acquired the old speeds gathered would effectively continue to be used.


----
A word about fuzzy ETAs and where they come from. They are not the result of segments being cut. Say you have a road which 40,000 daily drivers averaging 10 minutes from point A to point B. A parallel set of road going from point A to B only has 100 drivers a day, but averages 8 minutes. Waze may prefer the 10 minute route since the ETA is much more reliable. Let's imagine for a minute that the smaller service road actually has a real life average of 20 minutes, but with only 1 wazer about every 15 minutes, most of the traffic is not being recorded in waze. Some wazers get stuck for 30 minutes, others come when it's empty and zip by in 5 minutes. This high variance coupled with low number of overall data points (drivers) makes the server less confident that the average if produces will end up being a reliable estimation of the time it will take the next driver to travel accross the section. Since it feels the ETA isn't as reliable, it will prefer one which adds a small amount of time, but is very reliable. The assumption here is its worth the extra 2 minutes in this case to avoid a potential 22 minute delay.

Sent from Android using Tapatalk

Fredo-p wrote:Okay, so the nodes adding time issue is solved. Now back to the implementation of elevation changes. As stated before, which I agree 100%, there is absolutely no need to go and chop up roads just because a seagull can fly under it. That explanation/theory is beyond ridiculous in my opinion and causes to many issues.

We have the tunnel option now. That means that -1 as underground (which used to be used as tunnel until Waze finally created the tunnel option) can go back to what it and the other elevations were meant to used for (segments that go over/under each other).

As it stands, since Waze has not stated anything, elevation is for the use of identifying roads that go over or under each other. It is not for identifying what roads go in the air or underground.

So how do you propose to identify on the map which segments are bridges (including small bridges which go over a stream, or a road AKA overpasses). The tunnel flag explains how we can identify segments to be drawn as tunnels (the faded dashed outline segments). How do we identify to the server which segments should be drawn with the thick borders and shadows as a bridge.

Livemap currently uses the >0 elevation to make this determination. Even if we get a bridge flag, you'd still need to cut the segment to apply the bridge flag only where appriate.

Sent from Android using Tapatalk