[Page Update] How Waze determines turn/keep/exit maneuvers

Moderator: Unholy

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Mon Oct 13, 2014 2:51 am

CBenson wrote:
PesachZ wrote:The easiest instructions to new editors, when the wrong instructions are being given at a junction and everything is named correct, may be to set up a wayfinder.
Wayfinders stubs should be set without any alternate names.


Hold that thought. Waze staff is currently trying to convince me that ramp wayfinder stubs adversely affect routing. I'm not convinced yet. This is in connection with the routing issue raised here. The routing team doesn't understand why this segment exists. (So at the very least, the routing algorithms have been developed without contemplating what effects these ramp wayfinder segments may have on routing.)

Well first off Im not sure I'd believe they cause untoward routing effects. More importantly in these instances we only really need half a wayfinder (on the exit side).

Make the first 5 meters of this ramp be a no name segment.
{That will break the name match on the ramp, leaving only the type match for the Fwy. The ramp will get an exit instruction, the Fwy will not. And this won't add the ramp stub the devs, aren't sure if they don't like.}

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Mon Oct 13, 2014 3:11 am

pumrum wrote:
PesachZ wrote:Make the first 5 meters of this ramp be a no name segment.


Of course there are probably 1000 ways to solve this particular issue. I'm not sure that breaking the ramp into 2 parts is my favorite, since that would break our numbered route continuity concept at which point I may as well just remove the alt name from the ramp as it exists now and not add extra junctions.

I guess the points I was trying to illustrate was:

1) aren't we supposed to avoid clobbering hacks into the map to circumvent fundamental issues with the software? I know that guidance has been handed down before, but I'm mobile so I can't locate it just now

2) why would you ever, in any circumstance want a ramp as a sole right branch from a continuous highway to NOT give an instruction? It doesn't make any sense to me at all, given my limited but growing knowledge of Waze. If anyone can think of a reason, I'm sure PesachZ (the turn instruction guru) can :)

Short answer: because the best continuation algorithm doesn't differentiate what types of roads are in okay, just if they match, it would have to be written differently to give special handling to ramps. If you just think of it as two road types say a mH and a PS in the same setup, the PS might be the real continuation, and the mH the turn to a new rd given FC. That said, they seem to have no issues making these algorithms overtly complex, so why not add special handling for ramps to boot?

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Tue Oct 14, 2014 3:17 am

sketch wrote:
AlanOfTheBerg wrote:I cannot wait until we get the Junction Box so we can remove wayfinder segments completely.

I hope Junction Box is even what we think it's going to be. Some offhand comments by staff lead me to believe there's a chance that, while it'll allow native handling of U turns at divided-roadway intersections etc., it might not allow for some of the other things we have been expecting it to (viz., manual control of the particular instruction given and of the best continuation). I've also seen it referred to as "Big Junction" which seems to imply its function is handling large junctions (i.e., junctions between divided roadways).

I really hope not, after all the hype, that would be a huge letdown. They should see the need, and if it wasn't already planned, add it in. Then they can do away with all the stubs that they don't understand why we put there.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Dec 28, 2014 7:56 pm

Timbones wrote:I'm still struggling to get my head around these rules. Maybe they would be easier to understand if written the other way around, detail which combination of segments would produce instructions?

In particular, I'm looking for the simplest configuration which doesn't disrupt the detour avoidance algorithm and, if possible, doesn't require stubs. I've found a couple solutions that do work with stubs, but none without. I thought some of the rules on the alt name spreadsheet would allow at least one combination (rule #14 onwards).

My tests can be found here. See point places for notes, the two parks (green) are the ones that work.

The problem is we don't yet fully grasp all of the possible rules. I discussed this with waze last week in New York, and we are trying to get the final details ironed out. I'm not a hundred percent sure what you're trying to accomplish if you give me more details I may be able to give you a working scenario.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Dec 28, 2014 8:55 pm

Timbones wrote:I appreciate we only have reverse engineered rules so far, so look I forward to hearing what the devs say...

In my tests, I'm trying to generate 'keep right' instructions for drivers staying on the Freeway, plus 'keep left' for those exiting it (left-hand drive country). I'd like to find a simple recipe that will work for all our junctions, while at the same time preventing any off-and-on-again detours. This means keeping the primary name continuous on the Freeway. (Yes, I know I can use cross-matching alt name on a wayfinder, but that's a hack on top of a hack which I'd like to avoid).

I generally dislike using stubs, as they either look ugly or fall below Waze's 5m minimum. However, it seems that the only way to get keep left/right instructions is to use stubs, unless there's a configuration I've missed in my testing?

I think the reason I find the wiki page hard to follow is that it's all about how Best Continuation is determined, while I'm looking for the inverse; when Keep Instructions are generated.

If I understand correctly, you want a single wayfinder solution to work in multiple scenarios, and not employ any stubs. I'm not sure a signore solution is possible. We've been contemplating something similar on this side of the water as well. There may possibly be a way to accomplish this with a different solution for each scenario.

So you have a list of possible scenarios you are endeavoring to work this on?

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Dec 28, 2014 11:56 pm

Timbones wrote:The one working solution I've found so far is to use Freeway stubs, and the same alt name in all 3 segments (see Test B). This leaves the primary names unchanged, so if the rules change then the detour avoidance will still work, and the map hacks are not visible.

In the solution you proposed here, the ramp will get a keep instruction instead of an exit instruction.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Mon Dec 29, 2014 4:31 am

Timbones wrote:I think I could live with that. What would you suggest instead? Wouldn't ramp stubs result in an exit instruction to stay on the Freeway?

Currently ramps (or any type that's not a highway) give an exit only on the typical (traffic) side for that country . So for a typical size exit with ramp stubs, the exit gets an exit instruction, and the continuation gets a keep instruction even though it's a ramp stub.
This is why the wayfinder guidance note differs based on which side of the road the exit is on.

Keep in mind a single stub isn't consisted a detour, to alert the detour prevention handling.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Tue Feb 17, 2015 6:13 am

DwarfLord wrote:
sketch wrote:Ah, that may be the deciding factor then? From what I understand, disconnected routing is not per se "supported" and may lead to some weird stuff... I don't really know anything more than that, though. It does seem odd that this would give a turn instruction in any case.

Thanks! I didn't realize unconnected routing was considered unsupported since the app does try. I imagined it was either going to work well (although of course without real-time traffic adjustments) or it wasn't going to work at all, depending on whether app cached the necessary part of the map before it lost connectivity.

Maybe the app compresses its internal map cache so heavily as to corrupt best-continuation situations...?

Disconnected routing (calculating a route while not connected) uses only cached roads, not any other information about the roads. That's why there's no ETA, segment speeds are not cached. It also doesn't have access to the many route adjustments happening on the server side such as penalties based on road type, toll avoidance, TBTRs, closures, etc. It likely that the app doesn't have a built-in BC algorithm and that is one the "server-side" features you lose when not connected.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Thu Feb 19, 2015 12:58 am

qwaletee wrote:I would think we would not change things much.

For someone routing into the area, it won't matter at all, if they are sticking to route. For someone driving out or driving locally, I guess it could matter. Hopefully, they'll learn that Waze doesn't provide fantastic routing unless they start on Wi-Fi.

Many "lack of routing server" features wouldn't matter anyway. No traffic data? Can't change editing to account for it. Lack of TBTR? Before we had TBTR, we still mapped those turns, and got a UR once in awhile about restricted hours. And so on.

If you can think of a lost feature that might make you want to map differently, bring it up and we'll have a lively discussion.

Before TBTR the guidance was to restrict those turns entirely so we never routed an illegal turn. I wouldn't do that in port coverage areas though as it would affect all routes started with connection to the server.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Mon Apr 06, 2015 11:22 am

SeZAKxing wrote:Is there a minimum ramp length to generate an "Exit Right"?
Permalink

S-in is Major Highway "US-250 E, Charlottesville, Virginia"
S-1/best continuation is "US-250 E, Charlottesville, Virginia"
S-out is 50m ramp "Locust Ave / St. Charles Ave, Charlottesville, Virginia"
angles at ID: 43599247 179, 22, 160

Live Map

No the only minimum is that no segment should ever be less than 5m.

Keep in mind livemap may not give "exit" instead of "keep" the same way as the app.

Sent using Tapatalk for Android 4.4.2
[ img ]
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

PreviousNext

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: No registered users