Understood --and my preference would be to delete them with wild abandon.

Can you suggest a re-write that indicates that there is not a consensus on whether or not such turn restrictions are necessary?

Check the thread posted in the original message.


We have hundreds of intersections like this in Ohio. I've never seen a straight-through routing that couldn't be explained by faulty GPS receiver (or other user-specific app issues), "ghost" segments (or other map issues), or other transient problems.

We don't mark the restrictions in Ohio. Ergo, there is no consensus on doing so.

Jeff

[Edit: I think I'd be way less invested in this topic if someone could cite a recent conversation with waze staff that goes something like "yeah, there's a known problem in the routing engine that can cause that; go with a workaround until we get that ironed out". Otherwise, I can't help feeling like there's a bit of "cargo cult" driving this. ]

It would be great if someone could post some current URs where this happening -- it's really tough to explain which of the various map issues was responsible for something that's happened a while ago (especially given the different back-end infrastructures and and features/bugs that have come and gone).

It would be even better if one of the "champs" could get a reading on this from someone who has actually seen code.


Jeff

jhfrontz wrote:

BlazeTool wrote:Just an FYI for anyone following along. Discussion of routing off and back on via ramps has also popped up over here, referring to this interchange. For the record, the path via ramps is 1082 meters, via the freeway is 1100 meters.

I just got around to reading this, where there is a post that says:

jasonh300 wrote: There's coding to prevent that type of routing if the city name is the same on all segment before, during and after the ramps. However, city names often change at those junctions, so the simple solution is to remove the city name and therefore remove all doubt.

So I'm having trouble seeing how the "put turn restrictions on straight-through to prevent ramp-routing" directive isn't further qualified for pathological cases. What am I missing?

And I've yet to see anything in response to this posting-- which suggests that if the city names are the same on the off/on-ramps, there will be no routing (yet another example of something else that is causing the bad routing).

jasonh300 wrote:
One thing is for certain is that the naming should be consistent. If you run the Livemap Navigation script down that section of I-5, you'll see a "Continue on..." instruction at every segment where the name changes.

Is the "Continue on..." relatively new? There are several intersections in Ohio where the main route peels off on what seems like an exit, leaving some smaller route continuing on the straight-away. I've always heard that we should vary the spelling/spacing on the peel-away segment to induce a proper TTS instruction to "stay right" -- but I thought if the straight-through didn't have any discernible angle that there would be no instruction.

Jeff

You mixed me up with another poster. My issue was I495/DC beltway Exit 39 / RT 190 / Potomac MD headed south into NOVA. There was another user reporting this issue in Severn MD.

I was a little confused because I was thinking of a different type of exit ramp/interchange. I don't know if there are fancy names (like bow-tie, clover leaf, etc) but these are the two different types that I think we are talking about.

The one I previously described from the I495 beltway in DC is here:
https://www.waze.com/editor/?lon=-77.15 ... s=64105547

The off-on I think you are talking about is like this:
https://www.waze.com/editor/?lon=-77.86 ... s=52402273

In the 495 example, it would makes sense that I was routed onto the exit ramp and back on if traffic is slower on the main lanes (which it often is).

In the second example, I don't understand why waze would route you off-on. It is obvious that the exit with the stop should take longer (unless traffic is at a standstill on the main lanes).

These are two different things, though. A GPS error would take your icon down that road after you didn't exit and then eventually correct itself once you pass the exit. I've seen this and no harm done. You had already driven past the exit. In the 495 example, waze determined that the exit was faster and told me to go that way. I did and it was faster. Again, no harm done.

Can someone describe the scenario where someone is routed off-on? Is it just for traffic jams?

AlanOfTheBerg wrote:With more Wazers and more accurate traffic data, Waze is likely getting "better" at not doing this routing, but the fact remains that the code still allows it, even with no traffic impact, and that only makes it more likely to be routed like this when traffic on the freeway is backed up. This ramp-to-ramp route is illegal in many states, just like using parking lots to bypass traffic on a surface street.

Someone in this thread asked how to 'reproduce the off and on' ramp issue, and I think I know of a good way to do it, because I've found a total of two off-and-ons exactly this way.

So I start in say, SeaTac, WA with my Waze client in hand. I tell it to navigate to Centralia, WA. The logical route for this is I-5 S.

It'll compute a route. USUALLY the first time, this is a sane, straight through on I-5 route down to there. Here's where it gets interesting.

If I tell it to calculate alternate routes with the route button, it'll often come up with something else that looks ALMOST identical but isn't. And specifically, what it usually finds is an off and on, sometimes on a diamond, sometimes on a cloverleaf slip road. I already found one of these on exit 120 (Fort Jones, fixed with a slip lane crossover that allows a cloverleaf U-turn but not the I-5 off-and- on), and when I did the alternate route test again, found another at 132A (which I haven't touched, and in any case I'm satisfied of what I'm saying). I was doing this at 2 AM local time, so traffic ain't the issue.

I would conclude that at least at the present time, it IS in our interest to prevent off-and-ons with segment building or hard turn restrictions wherever possible, because the routing engine isn't looking deeper than off-and-ons for alternates as it is now - I just demonstrated it. The routing server only has so many cycles, and it testing whether off and ons are faster is kind of a waste, right? Thoughts?

EDIT: Oh, and...if you look at exit 132A (Permalink: https://www.waze.com/editor/?zoom=3&lat ... TTTFTTTTFT ), all roads in this area having to do with the exit are in the city of 'Tacoma'. No changes to and from one city to another. So it's still trying the off and on even if the cities are the same throughout.)

CBenson wrote:The name of the road changes from "I-5 S" to "I- 5 S" That is from without the space after the hypen to with the space after the hyphen. If the name remains the same waze shouldn't route this way.

By the way...are we all in agreement that the correct name for interstates now is "I-XXX", with no space, and we should make a project of seek and destroy wherever found? I see it go back and forth and back again in Washington and California at the very least, and if what you're saying is true, every instance of it going back and forth represents 'a different street' that the routing engine needs to check against. That's gotta be murder on somewhat longer trips. (In fact, it changes 45 times from SeaTac, WA to Red Bluff, CA as an example.)

Using the Waze Livemap Navigation Script, and asking it to route between SeaTac and Centralia, it shows that the street changes 7 times in that 70 miles, AND offers Exit 132A as an alternate...with, sure enough, exiting from 'I-5 S' and onto 'I- 5 S'...

I guess since 'street names' now relates to this topic as well, I also wonder if -- (whether or not shield generation will happen tomorrow or in a year ) Waze has come down with 'What they want Interstates, U.S. highways, state highways, and county roads to be named, with what spacing, and in what field - primary or alternate', for shield generation to happen,' so we can minimize the number of streets traversed, and the sheer number of 'correct options' for a road to be named, because crowdsourced edits mean infinite people will use all of them and figure it's all the same.

An example is that there IS only one proper naming convention for a county road, 'CR-XXX'. By definition, the answer of what to name a road to get it 'correct' is exactly that.

The fact that seven different things work to say the right thing for a state highway in TTS still means that spattering all the different variations mean more streets Waze must 'navigate' from point A to point B. Them eliminating this confusion would be most welcome, (and probably reduce the strain on their routing engine?)