I'm not understanding the purpose of this discussion. The wiki states that an elevation of -5 should be used for non-driveable segments. That statement is in conflict with the description of the railroad segment type. Thus, we should remove it.

I've made that change to Fredo's page: https://wiki.waze.com/wiki/User:Fredo-p/Elevation Why do we need to do anything else?

Here's the thing: Staff proposed that everything with a negative elevation be considered a tunnel (that's when they used the seagull as a prop). There was such an objection that they developed the tunnel box instead. At this point, I'm guessing all we're going to get from staff is something to the effect of "you told us that assuming that a negative elevation was a tunnel was a bad idea because negative elevations were being used for other things as well. Well, what were you using them for other than tunnels?" Eventually, it seems likely that positive elevations will be shown as bridges and segments with the tunnel attribute will be treated as tunnels. Other than that I'm not seeing that elevation matters at this point.

I'm recommend not basing any editing decisions based how features are shown on the live map. Many nice changes were made to the live map. You'd maybe have thought such changes were planned for the new look in v4. But I see we're not posting screenshots from v4.

PesachZ wrote:Perhaps because staff asked us not to set above ground segment to negative elevations??

Have staff reiterated this request since the tunnel attribute was released?

dmcrandall wrote: 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.

But waze staff has repeatedly stated including at the NY meetup that is not true. Has waze really told anyone that a junction node that has only two segments attached is processed at all by the routing server or includes traffic delay data?

Fredo-p wrote:When I see the word ground, I see ground level.

If the road is attached to the ground...even if it's an artificial incline, that is still ground level.

Stop trying to split hairs.

While we're talking about wiki updates...you might as well add the Best Map Editing page to the list. The Overall Goals section, to be more specific.

Usability
When it comes to the map, the first and foremost goal of editing is to provide the driver with a map that is easy to follow on a small display, and to produce sensible verbal instructions when (and only when) they are needed.

Needs to be changed to say shows every little elevation change.

Simplicity
It is not a goal to model the physical roadway lane-by-lane. Doing so often leads to unnecessary complexity--which means a cluttered map, confusing verbal directions, and lots and lots (and lots!) of extra map maintenance.

Needs to be updated to read, It is not a goal to model the physical roadway lane-by-lane. Instead the goal is to model the physical roadway bridge abutment by bridge abutment, regardless of the complexity, and extra map maintenance, added to the map.

Interesting. The OCD part of me won't let elevation go on for miles and miles. I've always clipped overpasses to reasonable lengths, mainly because I don't like the colors TB uses for elevations.

I've always edited with a road type heirachy in mind. The highest level road type was almost always "ground level." Anything that crossed over, or under, it was shown as +1 or -1, and the segment was cut to a reasonable length so that the elevation change only covered the actual overpass area (with a little leeway on either side).

This talk of miles of continual +1 elevation on roads is incomprehensible to me.

Sdtahoe wrote:I am fine with using the junctions of the ramps if the cross road goes over and the distance is reasonable like shown above. When the road goes under and the ramps are longer like this I like to see it broke at the bridges not the ramp junctions.

And to me, the pictured overpass is an acceptable length, and it already has the necessary junction nodes in place for an elevation change.

nzahn1 wrote:I'd still like to see a staff member spell out their stance on those (and other) word of mouth interpretations.

Come to a meetup, and ask them yourself if you don't believe other editors. Or, send them a PM. Maybe you'll get a response that is different than "ask your champs".

I still don't know why your giving priority of mapping overlap based on road class/type rather than mapping the actual configuration of the roads. Especially since the default view of Waze is 3D.

Because that is the mission of Waze. All throughout the wiki you find references to NOT mapping to the satellite imagery. Waze is primarily a navigation program. Navigation routing cascades from the highest level down to the lowest level.

At the last NA meetup, in NY, Waze told us that long distance routing primarily uses Freeway and MH road types in the initial navigation plan(to put is simply).

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.

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."