GSP Routing Errors - Express vs local in Monmouth County

Map Editors Community United States New Jersey
1

Hi All,

For the past year, we have had a consistent flow of UR’s along the GSP in central NJ, most notably around exit 105 heading southbound and 117 heading north. The users who respond generally report being routed off of the GSP to only be directed to re-enter again. It appears that most times it is a result of taking the opposite lane than waze suggested (taking express when waze directed local or vice versa). Awhile back we had some discussion around this and the general consensus was that it was a behind the scenes error with waze and an error caused from disregarding the suggested route.

Generally when traveling the GSP South I always take the waze suggested route but today decided to change it up and take local lanes when express was suggested. What I found was that for a majority of the trip south, waze still had me traveling on the express lanes because of the proximity of the segments. When I reached an area where express and local separated a bit, here it then recalculated and showed me traveling on the local lanes, and provided direction to take the next cross over, here ,back to express. This makes sense since originally it thought express would be faster anyway.

When I did not take the cross over to the express lanes, it still tracked me as if I did, and then had me mapped as traveling on the express lanes again even though I was in the local lanes. The next time, and the cause of the routing off/on error in my opinion, occurred at exit 105. At this exit, the local and express lanes spread further a part, causing a recalculation. However, when the re-calculation occurs, it instead thinks that I am on this ramp. This makes sense since it thought I was traveling on the express lanes, and when it senses that I am off track, this is the next closest segment I could have taken.

I hope this all makes sense. In short, it is not routing me off the parkway and back on, it is thinking that I have exited on the ramp and needs to get me back on to the GSP from there. The same theory looks like it would apply heading north by exit 117.

I would recommend that we pull the express lanes and local lanes as far apart as possible to force the recalculation of GPS location. I would pull the local lanes in to the right hand shoulder and the local lanes to the far left hand shoulder so it looked like this the length of the express/local lanes:

If we could get Waze to recalculate the GPS position away from the 105/117 interchanges, I believe it will solve this problem. Another added benefit is that traffic data will be more accurate. I have also dealt with reports in this area of “it said there was traffic but it was in the local lanes” or “it said to take the local lanes but that’s where the traffic was”. In my travels today, my speed/traffic data would have populated to the express lanes even though I was traveling local. I know there is no guarantee that pulling the segments apart will be enough to force the relocation, but I don’t see any downside to giving it a shot.

Thanks for taking the time to read all of this and hope it was worth posting. Look forward to hearing your opinions and feedback. Thanks!

Anthony

2

Do you think this is similar to what’s happening when a user is routed on/off the turnpike?

3

Possibly, but not necessarily. I have had it happen to me on the njtp around exit 7, but that truly was routing me off of the turnpike and then getting back on at 7a for whatever reason. I think this is giving the impression of a similar issue, but driving it and watching it live showed me it was different.

4

I’ve had this happen numerous times on the GSP in this exact area, and I have the same conclusions you do. I always take the local, never the express, so this happens every time for me.

I think there’s two mechanisms at play here. The first is GPS error and Waze snapping to the nearest segment. As you mention, there’s also another system that “assumes” the Wazer is on the routed segments. I think the big question here is how strong the latter is (it seems pretty strong). So on the GSP, we have both systems working against you potentially. My reasoning here is that I usually receive more accurate results if I’m not actively routing on the GSP (i.e. it has me actually in the local lanes more often).

My fear is that we’d have to pull the segments unrealistically apart to overcome both systems. I suppose we could pull them apart as you suggest to the extremes of the physical roadway and see if the situation improves. We should also start thinking on whether the SMs and RMs concur with potentially pulling them apart beyond the physical roadways to overemphasis the separation. Perhaps this just needs to be done in a few areas since there’s some stretches of the GSP where there’s nothing else around, and those could serve as additional recalculation points. Question here is what the error threshold is until Waze recalculates what segment you’re on. Put another way, how long do the overly-separated segments need to be?

5

I agree we don’t know how far apart the segments would need to be. I thought we could try separating to the edges of the lanes first and see what happens. I see little to no risk in taking this approach first. We can set it up and give it a test drive and then determine if additional action is needed from there. If we can separate the initial divide of the express and local lanes it may force the recalculation immediately which would be great. Unless there is something I am missing, it seems like a low risk high reward scenario- hopefully one of the SMs agree and we can test it out!

Sent from my iPad using Tapatalk

6

I’d agree that it’s worth a try and low risk.

With this in mind, I always have a similar problem on I-78 with express vs. local. I don’t think the problems it creates are the same, but I figure it was an interesting test since I was going through there anyway. The lanes are probably also closer together than GSP both in reality and as mapped, so it’s not a true test. That said, I stayed all the way to the right of the local lanes as much as possible, and Waze still had me in the express lanes erroneously. The route to the GSP always puts you in the express, but I prefer local.

7

I can’t tell you this won’t help, but I also can’t tell you it will, and its frankly, an awful lot of rather high-value segments that need to be touched in order to make it happen (The GSP is one of the state’s biggest and busiest roads, right?)

Generally, in an express/local scenario and assuming that traffic is moving comparably fast in both roadways, Waze will lean toward preferring the express roadway for any sections it can, including utilizing any crossovers available, so long as they don’t make you slow down too much or go too far out of your way (like with fancy loops and the like). This happens because of what I call the interchange effect, in which traffic using interchanges invariably moves a little slower just before using an exit or immediately after entering. Since Waze doesn’t consider lanes, it applies these speed variances to the entire roadway, thus causing the roadway with more interchanges to appear ever-so-slightly slower.

If there are any places where the above is not happening, and the local roadway is being overwhelmingly favored despite both roadways appearing to be moving at the same pace, that is a problem that we can look into.

We actually have a similar problem on the Turnpike, in which if northbound motorists don’t use the roadway Waze instructs, they will receive reverse directions at the split just north of Exit 14 because the directions are actually reversed from one roadway to the other. It’s a UR factory, frankly, that qwaletee is working on with Waze to see if anything can be done to mitigate the confusion, but so far I haven’t heard back from him.

At the very least, before proceeding with this, I would like to hear opinions from qwaletee and PleaseDriveFast. What say ye?

8

Thanks George for getting back to me. I definitely understand d everything you are saying about why waze prefers the express lanes. In this case though, where it is generating URs that look like it is asking you to exit off the parkway to get back on express (at exit 105) it is because it is recognizing me as traveling in the express lanes, and at this interchange, it just so happens that the express and local lanes come just far enough apart to recognize I’m not in the express lanes. When this happens, it snaps to exit 105 (off the express lanes) causing the error.

Also, since they are high value segments, I would ask one of the SMs make the necessary adjustments so there is no chance of disrupting data on these segments. My understanding is that if we just pull the nodes and never disconnect the segments we would be fine, right?

I hope I’m explaining the scenario clearly. I only could see what was happening by driving it live.

Sent from my iPad using Tapatalk

9

In looking at the gap between the the local and express lanes, I measured 190 ft at the widest point near the crossover at Exit 105 that Ant mentioned in his post. Consumer GPS devices are mostly accurate to approximately 200 ft, so I’m skeptical if this will improve the situation or even force a re-route at any other location. In most cases the lane separation will be under 200 ft when dragged to the edges of the road.

The scenario you described does make sense, but I see this a limitation of GPS accuracy. Until Waze can figure out a way to force recalculations at smaller intervals or GPS devices become more accurate, I don’t see a fix other than educating the Wazers on reviewing routes.

If we are going to try this change, I would want ARC or RC approval before doing so given the high value nature of these segments and the fact this is an experiment. Hopefully, as Phantom alluded to, qwaletee might have some insight from Waze regarding any potential solutions.

10

Thanks Matt for the reply and insight. I definitely agree that gps accuracy is a limitation, and ultimately, might not be able to be overcome, but I still think a test of this is worth a shot. I’ll go ahead and make my closing arguments as we wait for a final verdict here :slight_smile:

Unless I am missing something, the risk here is minimal at best. The manipulation of high value segments rightfully should raise some hesitation to make these adjustments. At the same time, it should also be the reason that we decide to try this out. The URs in these areas alone tell us that there is a problem here that needs our help. More than that, think about how many users experience this same problem but don’t report this issue. They still have a bad experience whether we see it as a tiny yellow bubble or not. It is our oath, as faithful map editors of this state, to protect the integrity of the routing for all users, especially on high value segments! My proposal is simply that we take a shot at what I described above. We can test drive it after the update and if it made no difference, we set it back.

The only con I can see is the risk of the high value segments which is why I think only a 5+ should make the adjustments.

Pros:

  • improved user experience for all us rebel wazers out there who chose to traverse the local lanes against waze’s better judgement.

  • improved accuracy of traffic data on high value segments in an area known for rush hour traffic incidents

  • UR factory will be in a limited production state in this area going forward

Thanks again for the consideration!

Sent from my iPad using Tapatalk

11

I prefer none of these segments are moved before talking this over with Qwaletee and/or possibly Orbit. Last I heard, we were specifically directed to position segment lines over the middle of the drivable surface - as best we could for an economical number of geometry nodes, right? - in order to prevent internal Waze errors for when either people drive too far away from where we drew the line, or when people’s GPS acts up and produces less-than-accurate traces.

I would like to hear them confirm that this potential for Waze errors is a non- or minimal-impact issue before we go experimenting with something that we don’t even know will work. Remember, the oft-mentioned 200-ft rule, especially around newer editors, is really based on a number of assumptions to explain things, in simpler terms, that actually involve a number of moving parts.

Also, don’t assume that you’re phone’s GPS, or even the Waze app, is limiting your accuracy to 200’. Your route trace will show the exact route you took, regardless of which way Waze was expecting you to go. The (roughly) 200’ threshold is based on an internal factor set by Waze to allow for a certain tolerance of GPS “noise” in your route before Waze decides you’re off course and spends more of your data allowance to calculate a new route. Sadly, this “noise” tolerance also impacts close parallel roadways in the same direction, as a side effect.

12

Your last point about the phone’s gps accuracy is exactly why I think this would work. I think it is accurate enough to detect the difference between the two lanes but it needs just a little nudge of separation. There is not a lot of other streets around this stretch, so “snapping” off of the parkway wouldn’t be likely. I will PM Qwaletee and Orbit and ask that they weigh in on here. Thanks again.

Sent from my iPad using Tapatalk

13

Synthesizing your conversation, I am fine with trying this, but it will only have a marginal effect. FIlling you in with some info I have:

  1. This approach has been tried (by me personally as well as others). It had negligible effect.

  2. You can only pull them so far apart before you risk collision with other road systems, or getting Waze confused when the user is actually following the suggested route.

  3. Waze is aware of the issue, but considers it low priority, so it won’t get revisited soon.

  4. Consumer GPS is accurate to 30m in worst case scenario testing - see http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=8292634

  5. When you do this, be careful with ramps. Especially when they run between the roadways. They should preferably diverge slightly more sharply/quickly than reality, to make sure that Waze does not snap a highway driver to them. (This does risk that Waze will not snap the driver to them quickly enough when the driver actually does take one, whether following the route or deviating from it, but it is a smaller risk, and one that Waze is more likely to correct quickly.)

  6. There can never be one rule. Differences in actual separation, angles, curves, junctions, and crossing segments will make for many possible unique approaches for various locations.

  7. Try this with a few dozen segments, and do not implement widely, without first discussing the results you see. Because of #6 above, you may also want to hold off even reporting back until you have achieved some expertise in the likely effect of each type of change, and have stabilized your piloy locations. If you do not have BotG it will also be hard to assess the result of each change. Try recruiting regulars for a route via UR before you make changes.

14

Also, a possible workaround to this problem, as I’ve started mentioning for similar problems on the Turnpike, is to, when it is safe to do so, stop your trip in Waze and then re-request a route to your destination, essentially forcing Waze to recalculate your route.

But there are a couple of caveats to consider: while it will put you on the roadway you’re actually on based on your current GPS position (to 30m or ~90’, as qwaletee said), there is no guarantee Waze will not try to utilize any crossovers or interchanges too large for BDP to get you back to that other roadway, which Waze initially determined to be faster anyway, even if just marginally faster.

Basically, we have to choose between potential overuse of people’s data and maximum accuracy on dual roadways, and unfortunately, there’s just not enough dual roadways in the world to make that concern a priority.

15

Quick tangent, but I thought I’d mention just for future reference. Just addressed a UR concerning the same kind of issue for I-287 here.