[Script] WME Toolbox

BellHouse has asked us not to discuss permissions in this thread.

This linked thread is the proper forum. Permissions are and will be different for each country.
https://www.waze.com/forum/viewtopic.php?t=146359

I understand permissions are the hot topic right now, but what bart just asked had nothing to do with permissions.

The functionality of the tool itself has been modified to not delete junctions on which there are turns or u-turns on, or something. Can we revert that change in functionality? That’s the question.

We still have permission to use the tool, it is the tool itself that has changed. Not a permissions issue. =P

Also, my request for an alternate name category/column in the segment list was completely overlooked too. =(

It isn’t a permissions issue, it is the functionality of the tool.

Previously, it would clean up superfluous junction nodes regardless if there were restricted turns or not. Now it will only delete those if all turns are allowed, which makes the tool relatively worthless. It was great for cleaning up a bunch of junction nodes after setting a direction of a street, which would have a bunch of nodes with their turns set every which way. Now you have to manually delete them one by one, which is very inefficient when dealing with unedited map.

Some of those nodes might be there on purpose, especially where U turns are enabled. On [url=https://www.waze.com/editor/?env=usa&lon=-90.11237&lat=29.95057&zoom=5&segments=83661333]a street like this[/i], divided in fact but not in Waze, the U turns are necessary for proper routing out, or else people leaving places on this street in one direction or the other might be brought on unnecessarily circuitous routes, wasting time, fuel, and patience.

The same may be true of regular restrictions in a few cases – places where you might have a “do not enter” onto a two-way street, for whatever reason. Not as common, but they certainly exist.

Both situations have this in common: they are easy to understand when you are working at the node-by-node level, and they’ll be completely missed using a “remove extraneous nodes” function at wide zoom.

On that segment sketch, u-turns are enabled and there are no turn restrictions.

I can understand the tool ignoring nodes that have an enabled u-turn. Obviously you don’t want to delete those. Although I wasn’t aware that the tool ever did delete those. Because of the enabled u-turn.

What we have now is nodes where the u turns aren’t enabled but none of the turns are enabled either. Those restricted turns now block the tool from being used whereas before they didn’t.

There is no case where a turn restriction on a junction in between two segments should exist in the first place; the proper solution is the use of a one-way segment on one side or the other. (The tool doesn’t delete junctions where direction changes.)

An enabled u-turn should block the junction from being deleted. A change in elevation. A change in direction. Heck, even a change in name or road type. But turn restrictions shouldn’t.

Again, not necessarily. There are situations where a road is “do not enter” on one side but two-way nonetheless. A car just past the node can go either way, but a car just before the node cannot. There is no one-way segment in this circumstance; both roads are two-way. You just can’t cross that node in that direction.

I don’t remember where I’ve seen this specifically. I know I’ve seen it somewhere in the Los Angeles area, at least. Regardless, they exist, and again, they are not readily ascertainable unless you are working node-by-node.

Sorry sketch, I know you’re more experienced than me, but I’m going to say no, there isn’t.

There is NO case where a junction with a turn restriction fulfills a purpose that cannot be replaced by a one-way segment on the other side of that junction. Even if it’s just a short one-way segment before returning to two-way again.

Specifically referring to two-segment junctions here and not intersections, of course. The kind of junctions the tool would target.

Now, if you’re saying some in the world exist, I’m sure they do, however I still feel they’d be better mapped using a one-way segment anyway. It’d look cleaner on the map and be easier to understand.

How is an extraneous one-way stub at all cleaner? It’s an extraneous one-way stub.

It’s harder to see at higher zoom levels (compared with the shift-Z of showing all turn restrictions).

Also, as rare as that situation itself is, I find it exceptionally unlikely that such a junction, if ‘correctly’ mapped to have a turn restriction, would therefore also NOT have the u-turn enabled for the poor soul facing that do not enter sign.

And therefore turn restriction aside, the u-turn itself being enabled would be all the protection said junction needs from the tool. Therefore having turn restrictions as a protection is unnecessary.

I’ll just put it out there that I too have seen cases where a street is two way on both sides of a node but you are not allowed to cross the node in one direction. This was in the middle of a block, not at an intersection. On one side the street the town erected a few bollards and a do not enter sign, the total length of the street which was essentially one way was about 0.3 meters, way below the minimum segment length of 5 meters. The only proper way to map this is with a node in middle a one red arrow. A node the tool would have removed, and from anything besides almost full zoom or street view you wouldn’t think twice about it.

These typically exist where HOA, or towns don’t want to inhibit internal traffic but want to keep people from making shortcuts through.

I’ve seen in more than one place, in more than one country.

Sent using Tapatalk for Android

One red arrow and an enabled u-turn. It’s the enabled u-turn that would make it a node the tool wouldn’t remove.

Red arrows are a dime a dozen and are the default for all nodes that get generated, on purpose or by accident or base import. Enabled u-turns are, if not completely editor dependent, at least majorly so.

A following list of rules (not complete) should help:

1 - If there are only soft turns on the node (the default setting of an untouched node that was generated by basemap), delete it
2 - If there are only hard turns on the node but they are ALL restricted turns (the default setting of an untouched node that was generated by an editor), delete it
3 - if all turns are enabled but u-turns are not, delete it
4 - If a u-turn is enabled, do not delete it
5 - If node contains a mixture of enabled and restricted hard turns (been touched/configured by an editor), do not delete it

This is of course not counting all the other checks of direction, elevation, road type/name, etc.

Sound good?

What enabled U turn? In many of these situations, you can leave through the node in question, but you cannot enter through it. No U turn is necessary or desirable to achieve full routing capability.

The other side of the node.

If you can’t enter, then you have to be able to turn around (or you’d be stuck there forever.) Hence, enabled u-turn.

It’s registered as issue #228, I just forgot to mention this here.

Yes, I agree it’s quite important to enable the u-turn at such places. Otherwise you might get routed through the red arrow, if there’s no other way. But this is now at the edge of being a Toolbox issue. :sunglasses:

Let’s try to keep some perspective though, I have more than 750,000 edits, and I can recall doing this maybe once. So, at least in my case, it has been a 1:750,000 occurance in two and a half years of editing.

The reason why I wanted to know what the developer’s justification for crippling the tool was. It is already restricted to AM/CM or L5+ editors, so we are talking about a rather small subset of editors that have access to it in the first place. So take into account the number of users that have never encountered the one possible instance where use of the tool has a negative impact, and we’re probably talking maybe a 1:1,000,000 (or greater) chance of someone accidentally deleting a node that was deliberately set. But it has immeasurable value in editing unedited areas.

I would be all for Thortok’s suggestions as to how improve the tool and maintaining its usefulness for cleaning up the map.

Just would like to thanks to the developers for fixing the “save bug”

Editing has been a pain since xmas, now it it is all good

Thanks

Question: Was everybody having this problem or was it just us with slower internet connections and much distance to the waze servers? For me the problem would come and go?

Release 1.6.4 is out for Chrome and Firefox:

1.6.4 (20150625) Fix: Redo roundabout no longer fails after having removed an exit segment (#224) Fix: Delete expired restrictions no longer deletes future restrictions on Firefox (#231) Update: Fix unneeded geometry now skips unedited basemap segments (#227) Update: Updated rights for Colombia, Denmark, Latvia, Netherlands, United Arab Emirates and United States Update: Permission strings (such as "[CM/L5+]") removed from help dialog, as the permissions are now set per country (#232)

Are we going to get this “fix” reversed sometime soon? It really has had a negative impact on the usefulness of the tool.

If it is needed so much, might be added an option to enable/disable this behaviour.