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

Don't forget that MapSir already mentioned this in locked V1.11 beta thread when tunnels was about to be released. We already have our answer from Waze on elevation. -1 IS NOT a tunnel. The tunnel option is what makes a road have a tunnel. Not -1. SO, mapping underpasses as -1 is normal.

MapSir wrote:The elevation attribute is a different thing, roads that underlap and overlap are not always tunnels.

qwaletee wrote:Yeah, and I'm still convinced that open cuts are NOT ground. The tunnel attribute makes an even better case for it.

Open cuts? You mean the narrow roads that go under another road? If so, -1 should be fine with no need for a tunnel.

I'd give priority to the 278 and make each overpass/bridge a +1. Maybe....MAYBE make the 278 a +1 when it goes over Atlantic. Or just make that small section of Atlantic a -1 right under the 278 since I don't see a need to chop up the 278.

I see having BQE at -1 to prevent having to chop up the other roads (granted it goes against the seagull theory but I never did like it). My only real concern is where the BQE goes over Atlantic Ave. What would that be?

robindlc wrote:Ground level. I do prefer to say 0 level. For me 0 level is the reference level. Set up by default. And for Spain we have decided that important roads such as freeways will keep this reference level 0. Any small road crossing it a different level will be +1 or -1 depending on its relative position to the 0 level road used as reference. This is to avoid as much junctions as posible in highways. We also have been told that the number of junctions do not affect the routing, but the possible mistakes yes.

This is actually how we map roads in Arizona. Elevation is set based on importance (Freeway, Highway, roads).

nzahn1 wrote:It's a pretty common symbol in cartography:

I've never seen it nor do I recall seeing a map key/legend in such a long time. With digital/online maps, you don't see them anymore (Gmaps, Bing Maps, Apple Maps(did it just get cold in here?)) Besides, no one is going to really care. All they want is to get from point A to point B and figure out how to quickly find the nearest Starbucks. We are attacking this elevation thing as editors and with the mentality that ALL Waze users know what we know. I'm pretty sure they don't and really don't care.

nzahn1 wrote: My only problem is this is not how things are currently shown on the livemap (which has become a stand in for what we can expect in the app). The livemap draws shadows under positive (+) elevations, and 'buries' negative (-) elevations.
If staff wants us to map differently than the only representation we have, they should tell us. So far we know the "tunnel" checkbox that will cause the 'buried' effect in WME, LM, and App. We don't know:

1. Will negative elevations (continue to) be shown as buried?
2. Will positive elevations (continue to) be shown as raised?
3. Will roads be stacked according to elevations when rendered?

Until we know ^the answers to these^ crafting guidance seems premature.

But we do know.

robindlc wrote:Tunnels. As explained, in Barcelona meetup was rejected the idea to link tunnels with elevations below zero. Now, with the checkbox for tunnels, these are two absolutely separated features.

Waze heard the complaints about linking tunnels to negative elevation and gave us the tunnel option. Thus removing the reference of negative elevation meaning underground.

robindlc wrote:Bridges. Also bridges are not related to elevations. If you think on a bridge you will probably be thinking on a bridge over a river... If a transitable road goes over a river or any other kind of landmarks, or even a non transitable road (such as railroads) there is no need to change its elevation (Said by Damian Abramovich in Madrid Meetup). So the "real" bridges (or what we have in our minds as bridges) are not linked to elevation.

We still don't know anything about a bridge feature, however, bridges where never mentioned by staff or in the wiki on how to map them. Therefore, it should be mapped in any special way.

robindlc wrote:Elevation. It is a feature we have to inform the system that two segments overlap but do not actually connect in the real world. Then the value of Elevation for each segment must be different.

I do not think that this definition/use of elevation has changed. I think the problem is how Staff/Devs worded the use of tunnels and included something along the lines of "hope in the future to show/render this in the app". This, along with the horrible seagull explanation, is what caused all the chaos and confusion.

I would love to burn the seagull alive, have that page removed, and keep it to what elevation was meant for (one road going over/below another). Giving priority to the highest level road class/type (by setting it to 0/ground) and working down.

Until Waze comes up with anything else, we keep it to its simplistic explanation and nothing else. I honestly blame the seagull and who ever came up with it. I hated it since day one.

robindlc wrote:Bridges. Also bridges are not related to elevations. If you think on a bridge you will probably be thinking on a bridge over a river... If a transitable road goes over a river or any other kind of landmarks, or even a non transitable road (such as railroads) there is no need to change its elevation (Said by Damian Abramovich in Madrid Meetup). So the "real" bridges (or what we have in our minds as bridges) are not linked to elevation.

I have a question about this specific section

If a transitable road goes over a river or any other kind of landmarks, or even a non transitable road (such as railroads) there is no need to change its elevation

what did you mean by this?

In the US, participating states map RRs as ground and junction them at every segment they cross as per the wiki. What do you set your RR elevation to? Do you have two segment types crossing over each other at the same elevation?

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

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.


Sent from my iPhone using Tapatalk

Because 3D has nothing to do with protecting the high pri roads. I'm not going to start hacking away at roads, especially freeways, just because "it's an overpass/bridge". Priorities go to the highest class first....etc

Freeways set to ground, everything else works around that. If one freeway goes over another, then the one that goes under gets set to -1. It's not a hard concept to understand. What I have seen, especially since the seagull crap came about, was a rocket scientist tear down and rebuild of a feature that was never meant to be used in such a fashion. Hell, I don't see any instruction what so ever from Waze saying to start mapping like this. It's unneeded and pointless.

I believe this is what he is referring to.

If you add a new node, you force that segment to begin collecting new data.
https://lh3.googleusercontent.com/-2CiE ... egment.jpg

Say you add a new node at the unnamed red arrow. Direction A1 will now begin to collect new data since this is a new node and no data exists at this location. This is now true for A2. However, the only data that is saved and still holds true is that of direction B1. By adding that one new junction node, you keep the data for B1 but have to start collecting new data for A1 and A2. Until enough data is collected, Waze should give it a penalty, as stated previously.


Now let's look at it on a Freeway (Interstate).
https://lh3.googleusercontent.com/-g-9l ... 252002.jpg

In this example, I chopped up the I-10, in both directions since there is an overpass and because "a seagull can fly under it" (horrible idea). The green arrows indicate the new junction nodes. The red arrows indicate the new data that Waze now must collect because no data on this junction existed in the past. This would case Waze to give not one but two penalties in a row. How would that affect long term routing? Especially if there was a MH or other FWY at some interchange? Would Waze give the user a reroute to avoid this one section?

Also, how long does it take for Waze to gather enough data to not penalize a newly added junction node?

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.