vectorspace wrote:The only determent I have found is that one could go wild just squashing red arrows, or perhaps forget and use it in the wrong place, and many times around divided roads, highway ramps, and the like, those red arrows are really necessary to impose valid turn restrictions.

Well since it doesn't change existing turn restrictions, I don't see how that's a problem.

vectorspace wrote:

bgodette wrote:

vectorspace wrote:The only determent I have found is that one could go wild just squashing red arrows, or perhaps forget and use it in the wrong place, and many times around divided roads, highway ramps, and the like, those red arrows are really necessary to impose valid turn restrictions.

Well since it doesn't change existing turn restrictions, I don't see how that's a problem.

You're absolutely right, I misspoke. This is not something to do with the node fixer script. I was thinking of the broader issue of someone pressing "qw" all over the place... a general issue for the full editor comment I was trying to express. I could see how an uninformed editor could wipe out valid turn restrictions without knowing it.

The initial reason for JNF was the to streamline the process of what 'qw' does, namely to lock turn restrictions, without the need to manually keep track of what turns were already restricted. It ballooned from there to fix other issues with nodes that were discovered along the way.

bigbear3764 wrote:

rottielover wrote: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.

paulkok_my wrote:

drive4fun2me wrote:I am running chrome and have crx version 0.0.7.7 but for some reason, I am unable to use it. I select a segment and press the "Q" on keyboard and nothing happens. Can someone please help.

If I'm not mistaken, you must have at least one turn arrow to be green in order for JNF to work.

Almost. The public version needs at least one restriction (either allowed or denied) to exist in a node for it to do something. If there are no defined connections, eg the node had been "disallow all turns" via the old Cartouche editor, node.connections would be an empty array.

PhantomSoul wrote:If so, I hope it's only available to CMs. I, for one, would not want anyone not familiar with the side effects and pitfalls of en masse QW editing to be able to do this.

In fact, I would suggest that for any non-AM editor, you shouldn't be able to use JNF at all on any junction that has at least 1 hard-disabled turn on it, while AM's should have to click past a warning. This way it's harder to JNF bomb people's edits.

??? the only side effects of the currently released version vs what an editor should be doing are:

It will disable U-Turns, which may not be desirable in certain areas. But since there's still no client support, it's not desirable for a driver unfamiliar with the area to have them to begin with. This has been the case since JNF's first release.

It doesn't split one side of a two segment loop/eye.

It doesn't handle parking lot/private stubs that only connect to the main road and nothing else that are one-way and converts them to two-way.

sketch wrote:JNF fixes soft turns. A mass-JNF tool has the potential to harden a lot of incorrect soft turns in areas that haven't yet been edited properly (you'd be surprised—a lot of the Detroit area is still like this). These are areas where turns should remain soft so the merger process can go about enabling more of them, and so editors are alerted to the presence of these areas.

Fair enough. I'm fairly certain merger still works on original nodes, but am unsure about anything we've created in the last 9 months or so, and that just goes back to the old discussion about WME defaults and incomplete work.

Updated to current dev.

doctorkb wrote:This script has been incorporated into WME Tools... Which is actively being maintained.

I'm not sure if any updates are happening to JNF.

??? it just doesn't need updates that often. AFAIK WMET just calls JNF if it's present.

doctorkb wrote:

bgodette wrote:??? it just doesn't need updates that often. AFAIK WMET just calls JNF if it's present.

There was a rash of updates to everything here a week or two ago to correspond with some change to infrastructure. Don't know details, but didn't see JNF update.

It was updated and posted into the beta forum the day the beta changed which was a little over a week before public, it just wasn't updated on Userscripts until the day the public editor was updated.

doctorkb wrote:Also, wmet now has all the JNF code builtin... Doesn't need JNF loaded.

Which is why I guess all those things JNF does that are niceties not directly related to soft/hard/self/rev/rbt/dead-ends/lollipops/loops that WMET doesn't do stopped working for those that didn't update.

The latest Chrome will disable non store extensions on startup, however if you have developer mode enabled you can delete the "local" extensions and re-add them and they'll work until the next time you completely restart Chrome again.