As far as your example about a left turn taking longer, if Waze has data for the intersection, it should know about that already. In addition, they've mentioned a new "junction box" feature that is being worked on. By the sounds of it, that will help to mark certain turns that are difficult or dangerous so that Waze will attempt to avoid them. I don't think that would really apply to a turn that is just difficult because of heavy traffic, but I haven't seen it and I don't know all of the purpose or value of it, so maybe I'm wrong there.

The detours around the block into a subdivision are a major nuisance that litter the map with all kinds of URs. I'd say they're almost as bad as the "route frequently ignored" MPs generated when unknowing, usually newer editors start enabling U Turns on the map.

Unless these so called junction boxes can associate traffic speeds with specific turns downstream along a route - and it would need to be more than just the next segment, traffic metering will never accurately be able to determine that an approach to a particular intersection, for example, gets severely backed up only in the left turn lanes. This is because traffic in other lanes whizzes by, diminishing the impact of that left turn backup.

I see this every day in my commute from work. Permalink example to follow...

On these 3 segments, the left turn lane gets far more backed up than the rest of the road - often due to heavy truck traffic that cannot accelerate as quickly as cars can. Because of this and the limited left turn light, it can take several times longer to get through the intersection than the other approaches.

Yet Waze almost always tells me to go this way, probably because the cars in the other lanes just whizzing by make Waze think it's the fastest route. Not if you need to turn left at Forsgate Dr though...

I didn't even think of that about the split crossroad, but it makes sense. On actual connector segment between the two split roads of Forsgate Dr, Waze would see both straight-through traffic and left turning traffic moving at the same speed. In the previous 3 segments of Cranbury-South River Rd, both left turning and straight through traffic would be exiting in the same direction, so Waze would just end up capturing the average of the fast straight through traffic and the slow left-turning traffic.

Now, during the PM rush hour (say, 5:00 PM), all 3 of the approaches to the NJ Turnpike here get significantly backed up. Since traffic lines up in both lanes eastbound on Forsgate drive, Waze ultimately sees that as slower than the average of the left-turning and straight through traffic from the Cranbury-South River Rd approach from above, and determines to go that way. However, in reality, far fewer vehicles get through the dedicated left-turn green light at the Cranbury-South River Rd approach, and as a result that route ultimately ends up taking much longer.

Not sure there is a solution for this without adding close parallel segments; I don't like to do that because they're more likely to corrupt speed metrics of other nearby segments that are too close for GPS distinction. I hear of upcoming junction boxes to gather and use better data on intersection turns, but will they be able to cascade information across a series of nearby segments to see where someone ultimately turned, as in an intersection like this?

Just to throw this in for consideration that I've mentioned in another thread... Michigan for whatever reason has almost every township added into the city layer. This means that basically the entire state is covered by "cities". What happens is that the "near X city" can become "near X township" because you're within the township and the city is a little ways away. And currently, most townships don't say Twp or Township, so it's not clear whether you're talking about a city or township in those reports. Even if all of those were fixed, seeing a lot of "near X Twp" just seems bad to me.

The main problem is in regards to ramps. So that is mostly limited to Freeways and some Major Highways. I don't think the city name really has any bad effect otherwise. The reason you don't want it to happen on ramps is that it can be dangerous to exit and re-enter the highway like that. Going around the block isn't the same.

As far as your example about a left turn taking longer, if Waze has data for the intersection, it should know about that already. In addition, they've mentioned a new "junction box" feature that is being worked on. By the sounds of it, that will help to mark certain turns that are difficult or dangerous so that Waze will attempt to avoid them. I don't think that would really apply to a turn that is just difficult because of heavy traffic, but I haven't seen it and I don't know all of the purpose or value of it, so maybe I'm wrong there.

As AlanOfTheBerg said, Waze does track speed for people turning separate from speed for people going straight. It could be improved, as he said, but it is there. There's a good chance that the reason it routes you that way is lack of actual speed data because few people using Waze are going that way.

As far as the URs for wrong driving directions, when I have looked closely into these, I've noticed that most of those are not issues where Waze is saying to turn right, go one block and turn left, go one block and turn left, and then turn right back onto the original road. In other words, they aren't issues where Waze is routing you off the road and back on to save time. Instead, these are usually cases where Waze is doing one of two things - it's either trying to get you to turn around and head the other direction or it's trying to take you down a side street over to some other road that it feels will be faster. The problem is that many drivers don't believe Waze is right and will just keep driving past the "turn around" instructions repeatedly and cause the MPs to appear or will just keep reporting wrong driving directions even though the directions may be valid. Note that there are issues with road types as well, where Waze may not want to use your route even if it's faster because the route has you going too long on a low classification road and Waze doesn't like that. So Waze will route you around a longer way to have you on higher classified roads. That's something Waze needs to work on and really has nothing to do with traffic or city names.

So most of those really are not at all similar to the freeway ramp problem (off and back on). Instead, they are usually wanting you to turn around or head off to another road to the side instead of using your current road. That may be because it's faster or because of how the routing engine treats lower classified roads. The latter needs fixed, while the former is correct and the users just need to understand what's happening.

Timbones wrote:

AlanOfTheBerg wrote:Some editors advocating for removing all city name info from all segments of freeways and ramps.

I prefer this approach, as Freeways and ramps are not addressable and won't be used for destinations. This also reduces "city blur".

Alan also said:

AlanOfTheBerg wrote:I think this is overkill and isn't representing the map correctly. Also, it makes Waze say "near <city name>" in hazard reports instead of the city name itself.

And if this is so, then this really causes me some concern. Someone in a given city who gets an alert about something that's "near" that city might not pay as much attention as they should, since they could come to the conclusion that it's just outside the city and they're not going that way, anyway. Heck, I could see myself falling for that, given that when I'm on the road, I'll glance at the display when something pops up - after all, I'm supposed to be keeping my eyes on the road, not studying the little screen of my phone up on my dash.

However, if a junction really is "in" a city, it matters little either way. Consistency is more important, particularly for routing.

I agree; consistency is a good thing. Unfortunately, I'm not seeing it in my area. I mean, I saw an area with a segment of freeway that didn't have the city name on it. The onramp going one way has a city name set, but the offramp for the same intersection going the other direction does not.

Where I live, cities are largely spaced out enough that one crowding into the other isn't as big of a problem as it would be in, say, the Los Angeles area. <grin> So that shouldn't be an issue here.

My personal preference would be for when a freeway passes through city limits, it should have the city name set (and on/offramps should follow suit). And if there aren't any real objections to the idea, I'm willing to start doing it in the areas I can edit. But this will go nowhere if I post an unlock or update request for the freeway and the response I get is something along the lines of "we don't do that."

CBenson wrote:

SuperDave1426 wrote:Where I live, cities are largely spaced out enough that one crowding into the other isn't as big of a problem as it would be in, say, the Los Angeles area. <grin> So that shouldn't be an issue here.

Well there seem to be at least five "cities" surrounding Las Vegas. Whether these should be used as cities for the freeways came up here.

Good point, though I live in northern Nevada, so my statement isn't completely invalidated. Reno does have some "other city creep" going on around it, but it's not quite as much as Vegas.

I think waze works better with most city names removed from freeways. Although as noted above, I do agree that there are issues with both approaches.

Yea. I wish there was a way to settle that. "I think it works like {blah}," "It seems to work like {blah}," etc., is fine, but it would be nice to know how it works for sure. That would settle the issue for good. Like I said before, I'm in big favor of consistency. And as noted, there doesn't seem to be a lot of it on this subject....

AlanOfTheBerg wrote:Some editors advocating for removing all city name info from all segments of freeways and ramps.

I prefer this approach, as Freeways and ramps are not addressable and won't be used for destinations. This also reduces "city blur".

However, if a junction really is "in" a city, it matters little either way. Consistency is more important, particularly for routing.