I’ve been getting reports out of West Texas along I-20 and I-40 about Waze directing people off of the interstate and back on. Unfortunately, these exits aren’t set up like your typical exits. I’ve been closing them out as “solved” because there is nothing wrong with them at all. I’ve checked connections a dozen times and there’s nothing wrong with the connections. I’m pretty sure traffic wasn’t at a standstill when these reports happen, as they sometimes happen by the same driver (assuming) because they’re all on the same day, almost one exit after the other after the other after the other. I’ve noticed it only happens in the rural parts of the state, but once you hit a town out there they stop being reported, so I’m assuming that there isn’t anything wrong with them. I’ve had Jasonh300 take a look at a couple of them before, but there’s nothing we can think of on what to do. Should I kick this higher up the food chain and see if the devs can figure something out. This is the type of intersection I’m having issues with. These URs come up going both directions. I’d love any advice anyone may have on this matter, too.
I’m curious, could you permalink a couple examples? Not necessarily of URs, but of these exits.
Sent from my iPhone using Tapatalk 2
I could have sworn I did.
Oh, sorry, must have missed it in Tapatalk.
It’s just directing them right off and right back on?
Aha. Looks like you have city names on the freeway, even for the bits near small towns. These should perhaps be generally removed.
Just to the east, detour prevention wouldn’t work as between these two ramps; the city names before and after (No city and Westbrook, respectively) don’t match.
It’s probably not a problem within cities because all the segments will have the same city name through the city. Once you’re in rural areas though, especially with tiny towns near the interstate, you’re gonna have a more inconsistent application of city names to freeway segments, considering their borders are often not drawn with the Interstate in mind.
I would remove city names entirely from freeways except as they travel through cities (as opposed to, say, towns). I don’t think anyone’s gonna have a problem with “Accident, I-20 W near Westbrook” as opposed to “in Westbrook”—I wouldn’t consider the Interstate truly a part of that town, anyway.
So I have seen this discussion of taking the City names off of interstate segments before, but still don’t see the reasoning behind it. Can someone please explain this?
Additionally, we have seen this along I-35 north of Austin and along TX-130 south of Austin. I don’t see any examples at the moment, but they have been there. These appear to have started happening about the same time that Waze started doing strange u-turns using the interstates and other limited access roads.
Detour prevention only works between two segments with the same “segment ID”—a number assigned to each combination of state-city-street name. So if you have I-20 E, no city, Texas, Waze will not give 2+ segment detours shorter than 5 km. But if you have I-20 E, no city, Texas on one end, and I-20 E, Westbrook, Texas on the other end, the segment IDs will not match, detour prevention won’t kick in, and you may be routed off and back on again.
It’s not usually a problem within cities because usually the city name in a city will not change between the segments just before and just after the exit and entrance ramps of the same exit.
“Alllll my exits live in Texas…”
What does that have to do with routing, and why. I remember reading about the possibility of deleting the city names on all interstates, but there was a lot of backlash from the rest of those who commented on it. As the city names helps us locate the issues when we get the emails alerting us to driver’s who have commented back to us. It also helps when “accident reported” issues, in the app. That shouldn’t have anything to do with why Waze is directing people off the interstates, though. That was just one example of many throughout West Texas.
Like I said in my previous post, it affects the detour prevention mechanism.
Detour prevention only prevents the following:
[Segment ID X] –> (detour) –> [Segment ID X]
It does not prevent the following:
[Segment ID X] –> (detour) –> [different Segment ID Y]
The Segment ID is the same for a given combination of Street, City, State. So if the segment before the first ramp of the detour and the segment after the last ramp of the detour have different City names, they will have a different Segment ID, and detour prevention won’t work
I was part of that backlash that didn’t like the idea of taking the names off of freeways, because of accident reports. However, I was mostly thinking of that in relation to cities, and I wasn’t aware of the mechanics of the detour prevention mechanism at the time. Seeing “Accident on I-10 E near Houston” is confusing when it’s clearly in Houston.
In a city, we can keep the city names no problem as long as we pay attention to how it will affect detour prevention. In the country, however, I don’t think it’s the same kind of problem. I don’t really consider a bit of I-10 that passes by a town to be “in” that town. “Accident on I-20 W near Westbrook” is perfectly meaningful to me. So the benefits of detour prevention working and an easier time for editors far outweigh that possible detriment, in my opinion.
As for tracking down user reports, well, that’s what the link in the email is for.
Here?
That one I can’t explain.
Thank you. That’s the problem I have with most of the exits in West Texas.
I had seen some segments in the detours that had “excessive” avg speeds like 800 mph and had thought that was contributing to the problem, but that last example doesn’t have any of those that I can see.
I’ve also seen these on the 130 Toll between Austin and Lockhart. Lots of user reports, and when I traveled on it recently I got the same instructions to exit and then enter again for several exits in a row (especially northbound).
Here’s a current report that looks like they’re having this problem (hard to tell because it only shows a short length of the track), but they are always popping up down there:
https://www.waze.com/editor/?zoom=4&lat=29.96437&lon=-97.67743&layers=TBFTFFTTTTTTTFTTTTTFTTTTT&env=usa
There are some sections of 130 south of the report with Lockhart listed as the city, but from experience the instructions would have been to get back on just after the intersection, and all of those 130 segments have ‘no city’. In fact, the instructions take you towards changes in both road name and city name (some sections of 183 there have Lockhart).
Another possibility could be a “miss-match” of the alternate names… This segment of I-27 north bound has an alternate name “US-87 N, No city”, as does the previous segment south, however the next segment north does not. Waze consistently wants to route me off at node ID: 53613092, and back on at node ID: 56340909 on the frontage road.
The alternate name of “US-87 N, No city” is in error, as US 87 is separate from I-27 from south of Kress to north of Tulia, and again from south of Happy to north of Canyon.
In the case of this UR, the west bound exits and frontage roads are not correctly associated with the city of Wildorado, while I-40 is, but there are no alternate names.
So, perhaps there are multiple scenarios that can cause this anomaly.
But the city names are correct in these instances.
When I’m looking for possible causes, I always try to include anything that is “different”. This can often help isolate the root cause, like a nested subroutine that appears fine, on its own, but when combined with “unexpected” data or combinations thereof, returns anomalous results.
Sent from my Nexus 7 using Tapatalk 4
I’m wondering if something changed on the back end.
To quote Scottie in one of the Star Trek movies… " I know those engineers , they just love to change things…"
Sent from my Galaxy Nexus using Tapatalk
Of the two links above, both have two way roads marked as one way. If this purely for highway routing, forgoing the locals ability to utilize the application and truth of the road?
It seems the problem may be related to use of the “service road” type. Little is known about this type, although it is said to be slated for retirement. I suppose we all assumed they acted the same as Street type segments, but it’s possible we were wrong.
@txemt and I discussed this privately a couple days ago. It seems he’s changed the roads to Street type to see if the problem is fixed that way.