Thortok2000 wrote: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.)

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.

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

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.

Probably because you are running a developer edition. Developer versions often do not have the same "protections" as releases.

taco909 wrote:Wonderful

How about eliminating Soft Turns and enabling "unconfirmed turns"

These are synonyms, I'm not sure why we had checks for both.

qwaletee wrote:Open Source is copyrighted, with a liberal use license.

It's really not that simple. It depends on the license terms. OpenStreetMap's license states something to the effect of "you can't use this information for your commercial purposes." If the resource that Glodenox is using states that it is free to use for commercial purposes with no attribution, then its license is different than OSM's, and it may be used without trouble.

SeveriorumPatrem wrote:This does not make sense to me, since I currently have JNF disabled. Nonetheless, the error did not get thrown until I saw this post and re-enabled Toolbox to see what would happen.

JNF is included in Toolbox as it has been for many years.

SeveriorumPatrem wrote:Learn something new every day.

Interesting that JNF is still listed as a stand-alone script, and I have it installed separate.

https://wiki.waze.com/wiki/Scripts/WME_ ... Node_Fixer

Yep, I do too. bgodette (the author) includes one or two little hidden features in JNF that Toolbox does not include in its implementation (I do not recall which exactly).

Toolbox code is specifically designed to check if standalone JNF is running and to disable its own JNF implementation if so.

Possible to move the measurement tool box so it does not block the zoom bar for those of us that actually like the new location?

iainhouse wrote:

sketch wrote:Possible to move the measurement tool box so it does not block the zoom bar for those of us that actually like the new location?

I just came across a note I made when I saw this request. It was something I considered fiddling with, but I didn't take it further.

Try adding this snippet after the measurement pop-up is created:

Code: Select all

$(".ToolboxMeasurementTool").draggable({ handle: ".header" })

For what it's worth, Toolbox did fix the overlap already