The place to get information and ask questions about everything to do with properly and successfully editing the Waze Map.

Use this forum for all general editing questions, and the sub-forums for specific types of Waze Map Editor features.
Sort by
Author
Post time
Subject
Display
All posts
1 day
2 weeks
1 month
3 months
6 months
1 year
Post Reply

Modifying the lock option (and some explanations)

Post by krankyd
EDIT (Nov. 28th 2011) - this change has now gone live on both US and WORLD editors. See details below the dashed line.

======

Hi guys,

Thanks to Shorty-CM and other wazers who sent us great feedback, we discovered a bug in the way our nodes and turn restrictions behave.
Basically, today you can have a situation where there's no connectivity (in cartouche) / you see a red arrow (in papyrus), but the routing will still route you through the turn.

This is happening because the turn was never set as 'restricted' (though it was never set as 'allowed' either). If it was never set as 'restricted', and waze routing server has no other information that indicates it is not allowed, it might choose to go through this turn, even though it isn't marked as allowed (in papyrus / cartouche).

As more and more people ignore this turn, waze will eventually learn that it is indeed not allowed. But in the meantime, wazers might get a wrong turn maneuver - and this is where this fix comes in handy.

To fix such a situation, we are tweaking the lock mechanism, as follows (all information relevant for Papyrus only, see below for cartouche):
* When you edit allowed / restricted turns for a specific segment, you are locking the turns for that intersection.
editing_just_turns.jpg
(222.33 KiB) Downloaded 1608 times
* If no turns are edited, the system will treat it as described above. That means, a user who makes the turn will open the turn to be 'allowed'. Once you edit at least one turn restriction on the node, it means all turns for that segment on that node will be locked.
* When you lock a segment, you are locking the turns on both ends of the segment. This is a bit tricky - especially for long segments - as you have to make sure you checked the turns on both ends of the segment.
locking_the_segment_turns.jpg
(260.01 KiB) Downloaded 1607 times
* Permissions-wise, locking will still lock the segment from being edited by another user who has a lower rank than yours. At this time, we're not going to lock the editing of turns (as we do with the segment), so even if the segment is locked, other users can change the turn restrictions.
* Driving direction of the segment is also locked (as before) from being changed by the analysis of drives.
* The segment's geometry is protected from being changed by the analysis of drives.

So, to sum up:
When you edit (even w/o locking) a driving direction or a turn restriction in the Papyrus you guarantee two things:
1. The routes analyzer (merger) will treat this driving direction as the true direction, and will not open it again (even if a person with a scooter, for example, drove the wrong way in a one-way street).
2. Our routing will treat this driving direction as the true one, i.e. will give a higher penalty for driving against the direction [28/11/2011 -This is still being developed, and will be implemented soon]


====

In the cartouche:
* We are more limited on the cartouche. When you edit a restricted turn, you are actually locking the entire node. We realize usually you work on all turns in a junction, but this is something you should be aware of if you're still working with the cartouche and not papyrus.

====

Note - Nov. 7th - the fix is not uploaded yet to the Papyrus. On the cartouche, it is already working as described above.
We will update you once uploaded and operational - should be in the next couple of days.


====

Finally, a short note about locking your segments as 'protection'.
Locking your segment guarantees that a user with a lower rank will not be able to edit your segment based on his 'drive-by' permissions. However, a user who's an area manager, will be able to edit any segment within his area, even if it is locked.
krankyd
Posts: 939
Been thanked: 27 times

POSTER_ID:84

1

Send a message
wazing like a hurricane

Modifying the lock option (and some explanations)

Post by gettingthere
CBenson wrote: But I have triggered them 20-40 cars back while I'm still 20-40 cars back. That is waze doesn't yet know what my speed for the segment is. This doesn't usually happen when I am stopped nearer to the intersection.
You are always on a segment if you are driving on a mapped road so data is being gathered which is being analyzed and feeding the system that determines whether to report a jam and to calculate and update the jam speed on the display.
gettingthere
EmeritusChamps
EmeritusChamps
Posts: 6092
Has thanked: 4 times
Been thanked: 69 times
Send a message
Last edited by gettingthere on Tue Nov 08, 2011 3:55 am, edited 1 time in total.
San Diego, California USA and Tijuana, Mexico

Re: Modifying the lock option (and some explanations)

Post by gettingthere
Let me provide a simple example to further clarify my position on jams.

Let's say you have two segments. Segment A, a junction/intersection (which happens to have a traffic light), and then Segment B. Each segment is 1 mile in length.

Let's also assume a very simple traffic light timing. 60 seconds green, 60 seconds red. For the sake of keeping this example easy to understand, let's ignore the time it takes to get your car up to speed and to slow down for the light.

Here is a MPH calculation tool: http://www.csgnetwork.com/directmph.html

Here are some sample speeds for segment A at a certain time of the day:
1 - 60 mph (green light, no traffic)
2 - 48 mph (red light for 15 seconds - 1 mile now traveled in 1.25 minutes)
3 - 40 mph (red light for 30 seconds)
4 - 34.29 mph (red light for 45 seconds)
5 - 30 mph (red light for 60 seconds)
average for segment A = 42.46 mph (212.29 / 5)

Let's assume that segment B average with multiple drives is 60 mph.

So if you get to this intersection and are in traffic and have to wait 2 light cycles (120 seconds or 2 minutes), your actual speed for segment A would be 20 mph. (1 mile, 3 minutes in the calculator linked above)

We don't know exactly what percentage of the average speed will trigger a jam. But we can assume in the case of waiting two light cycles that 20 mph is slow enough to cause a jam in a segment that has an average of 42.46 mph.

If you were drive number 5 above, likely 30 mph would not trigger a jam in a 42.46 mph average speed segment since it is not significantly slower.

If you add the average speeds of segment A and segment B and average, you get 51.23 mph (42.46+60 / 2). Remember that segment A already has the traffic light factored into the average segment speed.

If you remove the junction in Waze, you now have a single segment that we will call segment AB. The average speed for segment A+B is 51.23 mph as determined above. Segment AB already has the traffic light figured in to the average speed.

Using the same delays at the light as the first example, but the segment is now 2 miles long in total (segment AB):

1 - 60 mph (green light, no traffic)
2 - 53.33 mph (red light for 15 seconds - 2 miles traveled in 2.25 minutes)
3 - 48 mph (red light for 30 seconds)
4 - 43.64 mph (red light for 45 seconds)
5 - 40 mph (red light for 60 seconds)
average for segment AB = 48.99 mph (244.97/5)

Ok, so removing the junction does have a very slight difference in the average speed calculation for segment A+B vs. a combined segment AB. But this is not large difference and not likely to make a difference in whether a jam would be reported. An unknown factor is whether Waze averages the two segments speeds together or whether data has to be gathered again. If data has to be gathered again, it is possible that jams may be reported in a different way until there are enough drives to gather the new segment's average speed.

The 5 second routing penalty for a junction has no impact on this calculation since we are not discussing routing here.

Yes, likely the algorithm that Waze is using has some other factors. They certainly need to be filtering for people who have Waze running but are not yet driving (as to plan a route when not moving, browsing the map, etc). But I hope that this shows that the average speed and current speed is enough data to be used for jam reporting. The jam algorithm doesn't need to have a bunch of data factored in to work.
gettingthere
EmeritusChamps
EmeritusChamps
Posts: 6092
Has thanked: 4 times
Been thanked: 69 times
Send a message
San Diego, California USA and Tijuana, Mexico

Re: Modifying the lock option (and some explanations)

Post by gettingthere
I did a test in cartouche_old regarding combining two segments and the change to the average segment speed as displayed. We know that this is not the speed data that is being used in routing since Waze is using time of day speeds, so this may not reflect what is really happens when you remove a junction.

In this case, the average speed was totally different, in one direction, when removing a junction and combining two segments. If this is actually the case of how Waze deals with this, this could very well have some type of affect on the combined segment's average speed and how jams are generated. Of course over time this data will correct when Wazers drive over the new segment.

Here is a permalink to the new combined segment. https://www.waze.com/cartouche_old/?zoo ... 1=30839312

This segment was originally split into two segments as the screen shots will show.

Here were the before segment speeds in cartouche_old:

34/12 mph
39/27 mph

After combining:

37/1 mph

The 1 mph speed on one direction of the combined segment cannot be correct. If you look at the time on the original segments, it should have added 11 seconds and 13 seconds to total 24 seconds - NOT 806 seconds.
Before A.JPG
(108.96 KiB) Downloaded 761 times
Before B.JPG
(103.59 KiB) Downloaded 759 times
After.JPG
(108.16 KiB) Downloaded 758 times
gettingthere
EmeritusChamps
EmeritusChamps
Posts: 6092
Has thanked: 4 times
Been thanked: 69 times
Send a message
San Diego, California USA and Tijuana, Mexico

Re: Modifying the lock option (and some explanations)

Post by gettingthere
mapcat wrote:I also have observed that Waze knows you're close to an intersection, and will only generate "are you in traffic" prompts if you're stopped more than a few car lengths from it.
I am not disagreeing that Waze could be discarding the 'lowest 50 meters' as part of the jam algorithm. But this would be the lowest speed 50 meters anywhere in the segment. So yes, this filter could be effective when you are only stopped in a < 50 meter area at a traffic light. Or in a < 50 meter drive through restaurant. Or at a < 50 meter line at the gas station. Or any slow speed of < 50 meters anywhere in any segment. There has been nothing stated in the posts from The Fej stating that the 'lowest 50 meters' is in any way tied to or related to an intersection/junction.

So removing the intersection on the Waze map should have no effect on the traffic jam algorithm. This is the point that a few of us posting in this thread are trying to make.
gettingthere
EmeritusChamps
EmeritusChamps
Posts: 6092
Has thanked: 4 times
Been thanked: 69 times
Send a message
Last edited by gettingthere on Tue Nov 08, 2011 4:19 am, edited 1 time in total.
San Diego, California USA and Tijuana, Mexico

Re: Modifying the lock option (and some explanations)

Post by gettingthere
mapcat wrote:Wiki
I hope that the segment speed that Waze actually uses for routing is not corrupted like it shows in cartouche_old and as stated in the Wiki that you linked. If it is, this could be very problematic when you are removing many of these orphaned junctions on a freeway.

If you work on miles of freeway and remove a bunch of unnecessary junctions, the speed data could be 1 mph for miles and miles in one direction. This could cause serious routing issues and Update Requests for days/weeks until enough Wazers transverse the segments to get the speed data back to normal. It could take many, many drives to raise a 1 mph segment speed back to 65 mph.
gettingthere
EmeritusChamps
EmeritusChamps
Posts: 6092
Has thanked: 4 times
Been thanked: 69 times
Send a message
San Diego, California USA and Tijuana, Mexico

Re: Modifying the lock option (and some explanations)

Post by gettingthere
CBenson wrote:This makes no sense to me. Intersections/junctions define segments. If you remove an intersection, you now have only one "lowest 50 meters" section when there was previously two. This is very likely to have an effect on the traffic jam algorithm.
I agree that you would eliminate one of the 'lowest 50 meters' filters if you removed a junction and reduced from two segments to one. But why would this make a difference at one intersection for one traffic light? Each car takes up apx. 4 meters with space around. So that is 12 car lengths.

If the backup at the light is more than 12 car lengths, you could get a traffic jam if the traffic is at the threshold below what Waze uses to trigger a jam based on the current speed and the average speed on the segment at that time. So if there are lots of cars at the intersection and it takes longer/more light cycles than usual to get through the intersection, it really is a jam and should be reported.

If you remove the junction, the jam algorithm will still disregard the 'lowest 50 meters' where you are stopping for the light - it doesn't care where the 'lowest 50 meters' is in relation to the intersection.

Yes, if there is another traffic light prior to the next junction - you now have two traffic lights in one segment. So yes, in that case you would want two segments so that you have the benefit of the 'lowest 50 meters' filter two times.

So it depends on the situation. In the case that we are discussing here, is there another traffic light within a segment of this junction? If so, yes I agree leave the junction there (the one where no turns are allowed). If not, the junction where no turns are allowed can be removed to ensure Waze won't direction for turns without affecting the 'lowest 50 meters' jam filter to deal with the traffic light at the intersection where no turns are allowed.

Although the satellite imagery at this junction is not good, it appears to me that there would be no other traffic light in the adjoining segments since it is a ramp from a major highway to another major highway. So removing the junction should not affect the 'lowest 50 meters' jam filter and jam reporting will work the same as it does now. This is assuming that there are not other factors involved in the jam reporting algorithm.
gettingthere
EmeritusChamps
EmeritusChamps
Posts: 6092
Has thanked: 4 times
Been thanked: 69 times
Send a message
San Diego, California USA and Tijuana, Mexico

Re: Modifying the lock option (and some explanations)

Post by gettingthere
Shorty-CM wrote:It's more important for Waze to fix the bugs than it is for you to find ways to avoid them.
It's a moving target. There will always be bugs.

As editors and forum participants we are more educated than the average Wazer who is not an editor, who is not following the forum, and who doesn't understand the complexities, issues, and how to work-around them.

It is a perfectly acceptable work-around to remove the intersection as was suggested by others earlier in this thread. No turns there and from all of the detail that I have spent a lot of time working on shouldn't affect traffic jam reporting. Sometimes we need to spend some time analyzing the way that things work, with partial information, in order to justify the means to an end.

If we can't accept that as map editors we will have to come up with creative mapping to work around other issues, maybe map editing for Waze is something that not a good fit...

It's great that Waze took your input regarding the turn restrictions issue and is going to apply a fix. Great job!

But as you know these type of issues can take a long time to fix, if they ever get fixed. That should not stop you from being able to edit the map and sometimes come up with creative ways to work around other issues. Can't always be done, but sometimes a workaround is totally acceptable.

This may not be a good example but on a route to work that I take daily, there is a sign posted 'no left turn' along the route. This intersection in in Mexico, so maybe some other rules apply. But every single person that comes to this intersection make the left turn. Even when the police are right there. In fact, even the police make this illegal left turn.

So how would we deal with this in the editor? Do we expect Waze to do something to fix this (allow a turn that is not allowed). What have I done as an editor? The turn is restricted, every day Waze instructions me to take a longer way, but I just do as everyone else is doing, turn there. Waze recalculates and I can still make it to my destination. Sometimes Waze needs to be ignored and you need to make a decision as a driver, not a Wazer. Should I allow the turn in the editor? Up to now I have sided with rule of law. But reality is that the sign is invalid and no one is following the law. Maybe at some point I'll allow the turn ... Things are not always as straight forward as we would like...
gettingthere
EmeritusChamps
EmeritusChamps
Posts: 6092
Has thanked: 4 times
Been thanked: 69 times
Send a message
San Diego, California USA and Tijuana, Mexico

Re: Modifying the lock option (and some explanations)

Post by jasonh300
Shorty-CM wrote:Go crazy with 'allow all directions' along big, long stretches of highway. For, like, 4 hours, and then cry as you notice this now means that the whole thing allows driving the wrong way. And then spend another 4 hours fixing it in cartouche. Heh. Where 'allow all' works with 1-ways. For one example.
I'm not following...How does "allow all" not work with one-ways in Papyrus?
jasonh300
EmeritusChamps
EmeritusChamps
Posts: 7568
Has thanked: 131 times
Been thanked: 533 times
Send a message

Re: Modifying the lock option (and some explanations)

Post by jondrush
I've observed just that. I've never triggered a traffic alert sitting within a few cars of a red light, but if I'm 20-40 cars back I have triggered them. Waze is a little bit smarter than the average bear . . . :lol:
jondrush
EmeritusChamps
EmeritusChamps
Posts: 2660
Has thanked: 73 times
Been thanked: 375 times
Send a message
Post Reply