Doesn’t the original post explain that it simply overrides the Q key shortcut function? It reads that way in the quote that you included in your post. Seems pretty clear to me.
Tapatalk made me do it.
Not everyone understands “overload” I had to read it a few times to understand what that meant.
Did the new version of the editor break this script? I can’t seem to get it working for some reason (Chrome)
I haven’t had any problems with it.
Sent from my iPhone using Tapatalk
Hmm. I’ll do some more testing. When I have JNF active, saves take forever. When I disable it, it saves quickly. Maybe one of my other scripts is interfering.
Sent from my iPhone using Tapatalk
Now you got me thinking about it. Thought the slow saving was from the URs’. Seems if I edit, it’s fine. Close a UR and edit, it locks up. I’ll have to give a try with JNF off.
JNF intentionally forces a wazeModel refresh (loading road data) post successful save to deal with the inconsistent segment attributes of any segment that was modified during that save. This means saves can appear to take longer if the road data (Features) is slow to respond.
Hi Brian
I would like to make a suggestion for some new functionality for this script. I don’t imagine it will be particularly simple, but I suspect this script is the place to add it and you’re the man with the skills to do it. 
I’m sure many editors have come across the occasional “corrupt junction”: where all the geometry and turn restrictions are correct, yet Waze still will not route correctly through the junction. The solution is to note the current turn restrictions; pull each segment (including the last) away from the junction node allowing it to disappear; rejoin the segments again; move the node back to it’s original location; restore the turn restrictions.
The first part of my request is a way to automate this procedure. It wouldn’t be done very often and should probably not be made easy to do (to discourage people doing it when there’s no point). Perhaps only accessible through a button on the left-hand panel or an unusual key combo (ctrl+shift+Q perhaps) with a confirmation pop-up before rebuilding the junction.
The second part concerns actually identifying these nodes. I don’t even know if it’s possible to identify that a node is corrupt in this manner. We may well have to provide you with examples to look at. 
If it is detectable, then the above methods suggested for user access to fixing it would not be necessary: the script could simply fix the node as part of it’s normal fix operation.
Further info: If I put JNF into chrome directly (drag and drop the .js into the extensions page) it works fine.
When I was trying to use it via “Tampermonkey” it said it was loaded but wasn’t working.
Hope that helps.
Anybody face problems with v0.0.7.5 or V0.0.7.6 today? When I go into WME, I get lots of red arrows showing on the map without me clicking on the segment. I can see this when I zoom in at 100m / 500ft.
Problem solved. Sorry to throw a false alarm. I must have accidentally pressed Shift+Z causing all the red arrows to come out.
Please remove fixing of U-Turns. Now as they are released, this function destroys them.
I’m of mixed thought towards this. Most segments shouldn’t have a u-turn enabled.
I guess as long as Colours & Highlights continues to point them out, it doesn’t matter much whether it’s in this script or not…
Actually most segments “should” have a u-turn… you can do this on most roads and junctions.
And highlights just informs about it… but this script by default removes u-turn.
It depends on your jurisdiction.
In Canada, most segments where you would want to do a u-turn, you can’t (legally). And most where you can legally, you wouldn’t want to attempt it, as it isn’t safe.
The law for the province of Alberta is for any junction of roads where it is safe to do so, providing it is an uncontrolled intersection – so if there are traffic lights, no u-turn. Oddly enough, those are usually the only intersections that are big enough to do a u-turn in.
And yes, I know that highlights just points them out. But I also see no problem in obliterating them with JNF – as long as users using JNF know that it will happen.
Technically, the only thing JNF needs to do now is deal with the revconns… both u-turns and soft turns can be dealt with in WME… so JNF just makes things easier.
+1
In the UK, the vast majority of currently enabled u-turns appear on single segment streets at junctions where u-turns are physically impossible. I suspect that they have all been created by users effectively doing a 3-point turn at the junction using one of the connected segments - all within too small a space for GPS resolution to see what’s happened. Waze then soft-enables a u-turn.
The result is that the client will (if it wants to turn the driver around), try to route them to do a u-turn where none is possible. Of course another issue is that the client can’t actually give a u-turn instruction yet, but that’s a whole other discussion. 
At the few junctions (compared to the total number of them) where u-turns might be possible, they’re specifically forbidden more often than not. That’s simply because our ancient UK roads don’t normally have wide enough carriageways or dividers to make it easy to do. From a UK perspective (and I fully understand that this does not apply worldwide), I would far rather JNF removed u-turns and I had to put them back afterwards - it would be the most efficient way to work here.
I’m sure we’d miss enabling some u-turns that are OK, but MPs and URs will help to alert us to the realistically small number that are actually legal here.
I tend to disagree. A lot of segments and junctions will be mapped where road marking restrictions forbids legal passing, never mind u turns. You tend to forget that every segment junction does not really terminate where there is an intersection and I would guess many of them are in places where visibly of oncoming traffic is not taken into account.
Just take a connection between 2 adjacent segments on a 4 lane major highway mapped as a single lane as an example. Should that have u turns enabled by default? I think not.
The last thing a stupid driver needs is an app that tells him /her where to ‘legally’ make that u turn.
Sent from my HTC Sensation Z710e using Tapatalk 2
We have enough of those in South Africa, don’t we? :lol:
I am definitely in favour of not having u-turns enabled by default.
I’d better stop turning round like that then! Maybe if the client just said “turn around when safe and legal” rather than using the phrase u-turn. To me a u-turn is any manoeuvre that gets you facing back on yourself (reversing into a side street and then driving out is a u-turn in all but name)
Sent from my GT-I9300 using Tapatalk 2
No intention to hijack the thread, but I think it’s a worldwide epidemic. If someone can get stuck in the middle of Oz or drive off a pier simply 'cos the SatNav said so, just imagine the spectacular u turns that will follow.