[Script] WME Color Highlights - 2.33 Sept 2020

Lastly: RevCons? SelfCons? Can someone tell me what these terms mean?

Have a look at viewtopic.php?f=265&t=42562. I posted an explanation earlier today.

I'd still love to see WMECH stop highlighting selfcon. It seems like an "error" when there really isn't.

I have to disagree with this one. Selfcons allow the client to act in an unacceptable way. I'll quote a specific example from my own beginnings with Waze. My normal route to work travels for a mile or two before reaching a T-junction. At this junction, Waze always wants me to turn left, as that leads to a route that is mostly major highway with good speeds. However, it is also a route with some tricky junctions driven by too many idiots who don't pay attention to what's going on, or are in such a hurry they think they can take whichever lane they like & then barge into the right lane at the last second. It's the sort of thing I can do without to start my day, so I turn right at the T-junction and take a quieter route over smaller streets that is rarely slower than the other route.

When I first started with Waze, I would turn right and the same thing would happen every day. At the next junction my purple line would disappear and I would get no instructions. On checking, the route was, in fact, folding back on itself to proceed as if I had taken the left at the T-junction. The next instruction would be a turn right a mile further down that way. Waze would not stop doing this until I had disassembled & reassembled the junction to the right of the T-junction (I didn't know about selfcons at this point). Eventually we got an update (they were much slower in those days) and Waze started trying to do the same at the next junction. Same fix, long wait for updates and Waze started to route me round a block to go back.

That was fair enough. Waze didn't like my route - I could accept that - but at least it was sensibly telling me how to go the other way. By the time I had gone 2 junctions up the "wrong" way, Waze would decide I knew what I was doing - presumably a recalc on the new route seemed reasonable by that point. But occasionally it would still think I could u-turn at the 4th junction. I just ignored that - until highlighting for selfcons became available and I found a selfcon there. Got rid of it and no more u-turns without instruction.

I have also cleared a couple of URs where the Waze-provided route showed this u-turn behaviour at a node that had a selfcon.

So, my problem with selfcons is that they effectively allow Waze to route a u-turn at the end of a segment you are driving on but the client has no instructions available to handle this manouevre. There may well be an argument that u-turn behaviour like this could be useful - but if it is, then the editor needs to show the selfcon arrow by default (without the use of scripts) and the client needs instructions to give to the driver. Unless that happens, I believe selfcons produce unacceptable and confusing routing in the client.

If Waze is going to have a properly defined u-turn functionality, I have no problem with it. But I'll make a few points about that:

First of all, we need to be told. This is the first I've heard that this behaviour might be deliberate. Of course, it might have been discussed in the champs forum, or I might have just had my head up my ass (happens frequently ) and I missed it.

Secondly, the arrows for these u-turns must be visible & controllable in the editor. And yes, once this happens, there won't be any need for the script to highlight them. I'm sure it only does so now because selfcons are a hidden junction property that has a direct (and problematical) effect on client routing.

Thirdly, Waze needs to stop automatically creating these u-turns. There are areas where I have removed all the selfcons I could find and they are gradually re-appearing again. This can only be because people are actually doing u-turns (or 3-point turns, or going just around a corner and reversing out again), because there's no way for us editors to create them. I presume Waze then creates a soft-allowed u-turn. However, just because one driver managed to do it does not mean it will be a safe or sensible manouevre. I know of junctions where u-turns aren't prohibited and are quite easy at 1am, yet would be suicidal at 8am.

Lastly, the client needs to handle u-turns with an instruction like "at the next junction, make a u-turn" and a visual navigation instruction, rather than silence and a purple route that apparently comes to a dead end.

Given the numbers of them that I encounter and their random locations, I would suggest that, should this functionality go live, it would have to be preceded by a system-wide removal of the existing ones. Then we as editors can put in the ones that really should be there.

None of this is "complaint", BTW. It's just important points which I think might need some discussion. For that matter, there should probably be some discussion on whether u-turn functionality is a good idea or not. And it all may have been discussed already, in which case I apologise.

I'm still not convinced selfcons cause routing problems (if all other roads are correct).

I'm sure they do and I've experienced it. Right now, the problem is that the client simply doesn't provide proper instructions for them. But, longer term, the sheer random distribution of them is the problem.

In some areas, I've seen as many as 1 in 10 junctions with selfconns. Once the client handles them properly, that still means there will be 10 more-or-less identical junctions, only 1 of which will give you a u-turn when Waze wants you to turn around.

Assuming that u-turns can also be "soft" or "hard", I think the only realistic solution is for Waze to run a cleanup and change every soft-allowed u-turn back to soft-restricted and then stop soft-allowing them. That will preserve all the hard u-turns presumably set by editors.

Mind you, I suspect our American cousins will disagree - but then they have far more roads that are big enough to do proper u-turns. I reckon the vast majority of ours come from people turning corners and then reversing back out the other way.

You're quite right Alan. I never say that how I mean to - and you always call me on it.

I mean u-turns at a junction where the turns are all soft/unlocked should be changed to disallowed. Presumably, if the turns are hard/locked, that's because an editor has set them and an allowed u-turn is supposed to be there.

My understanding (little as it is) is that u-turns were, until recently, not a "proper" or intentional feature. I think the best time for a database cleanup would have been before they became settable in the editor, because none of them would have been confirmed by an editor at that point. Now, any cleanup is likely to impact intentional settings by editors.

I have little experience of what it's like over there, but here in the UK, the vast majority of urban intersections simply aren't big enough for most cars to do u-turns. In fact, one of the special features of London black taxis is a drastically reduced turning circle to allow them to make u-turns where most normal cars would have to make a 3-point turn.

What if I were to highlight only soft U-turns? Or at least differentiate them from hard U-turns? (Accepting above comments about all or none locked)

By differentiating u-turns by whether they are at a locked or unlocked junction, we can give them different treatment.

• A u-turn at a locked junction has been set by an editor (inadvertantly or not), so deserves some consideration as to whether it is right or not.
• A u-turn at an unlocked junction will be down to the routing algorithm setting it. We can then treat it appropriately for the area. If I saw one in a UK market town, I could be pretty sure it shouldn't be allowed. If it's on a large multi-lane surface street, then it would probably be OK, subject to checking signage.

As an aside, and with respect & thanks to Alan's patience with those of us who get it wrong, I am going to try and stop referring to hard & soft turns completely. Instead there are just turns, which appear at a locked or unlocked junction (it doesn't seem sensible to describe a junction as soft or hard anyway). If the junction is unlocked, Waze can change turns from disallowed to allowed.

I wouldn't start calling them "locked" or "unlocked" -- because that will confuse younger editors who see the "Lock" button and think that's how to lock turns/junction. I think "soft" and "hard" are the unique identifiers that everyone understands.

You're not wrong! I must admit I'm following AlanOfTheBerg's phraseology there - because I'd be crazy disagree with him.

Even though I think it sounds a bit wrong, I could live with calling them soft & hard junctions. I'm sure Alan will be along in a minute with his opinion, a better argument and to point out whatever other confusion I've introduced.

Try WME Toolbox (viewtopic.php?f=8&t=48123) by Oyyodams. It includes a single key-press function to remove the geometry nodes from the selected segment.

I'm using it in Chrome (latest "standard" version) and with both WMECH and WME-Addons. I know that Toolbox relies on the presence of WMECH for some of it's functionality and it may need the latest beta version (1.64).

For some reason version 1.6.2 and now 1.6.6 is picking up the version number from WME-Add-Ons. That is, in WME the highlights tab shows version 0.44 when the chrome://extensions/ page gives the version as 1.66. The extensions page shows WME-Add-Ons as version 0.44. Not really a problem, just a nuisance to always have that little update flag flashing in the highlights tab because it is comparing itself as 0.44 instead of the correct 1.66.

I encountered this problem around the time the Chrome update started breaking all the .js scripts. As I recall, it turned out I had 2 versions of one of the scripts installed (may not have been WMECH itself).

I suggest you double-check your extensions tab & make sure this hasn't happened.