Validator has a built in check for a lock (any rank above 1) on freeways segments only in the USA AFAIK. But I posted a custon check above which you can modify for whatever road/rank settings you want, the one I posted is for the Northeast-New England region Urban Standard.
Fwy, MH - 5
Ramp - 5 (though we set them to match the highest rank they connect to (usually 5 so that’s what the check is for)
mH - 4
PS 2
Sent using Tapatalk for Android 4.4.2
Cool, thanks for that info. Personally, I still think any such tests built-in to one of the addon tools should:
Thaks works great whit Opera too!!
Thanks for your replies PesachZ and SuperDave1426.
I know it is also possible in validator, and it’s a localized thing. It was available in the Netherlands, but i’d have to check why it’s not anymore. And I agree, it’s a validation, so that might be the best place for it.
I’ll try playing with the custom check, although i’m not that familiar with such “language”.
Maybe my post wasn’t clearly showing, but my main question was actually the first sentence, if anyone is using the toolbox functionality related to this, and specifically if any countries have the automatic lock set on other levels than 1.
The proper autolock levels are currently only in the beta WME, AFAIK no country has it in production WME.
Unfortunately toolbox is not working in beta WME yet.
Regarding this: Fix: Suppress unneeded junctions too aggressive , I’ve never experienced that.
What i did experience, was that Validator marked unneeded junctions on 2 segments with an opposing A–>B direction, but toolbox didn’t remove the node, as on segments with similar A–>B direction.
Oyyodams didn’t fix that, but I don’t know if it was lost in the flood of forum posts, or just not that easy to solve.
If you could have a look at that?
you’re right, but that auto-lock is based on traffic lock, i think, and not on a set standard scheme.
Of course, but that’s all what automatic is about. There was never an intention to provive an autolock level based on local rules like highways L3, freeways L5.
I guess Oyyo had the best idea about it in providing the comparison function in showing if manual lock is below (red), equal (blue) or above (green) traffic based autolock level.
Started this in Vienna, increasing the locks from standard set value to autolock level on segments, where standard set would be lower than traffic lock…until TB seized to work in beta WME…
I don’t know whether there’s a subtle distinction between proper autolock and the autolock we currently have in the UK, but we certainly do have autolock on the main WME.
If you enable the “manual locks less/equal/greater” feature in Toolbox, so far as I can see, you have to have all three. In other words, it highlights all roads with a manual lock, which effectively means all of our major roads. Not a great deal of use, especially since the lock highlights obliterate all other colours.
Would it be possible to split this feature into three? I’d find it particularly useful to be able to highlight just roads which have a manual lock below the autolock level.
There’s a particular highlight I use from WME colour highlights, for ‘recently edited within X days’ where you can customize X.
However, I’d /really/ like it if it was ‘recently edited by someone else.’ When I start doing edits, the highlight becomes overpowering and then I can’t see anything.
I know it’s the other addon, but if you added it to toolbox then I could turn it off in the other addon. =D
What exactly should we look into?
Right now Tb removes the node only if the 2 segments have the same direction (which I think is the way it should be). Validator highlights differently, yes, but that’s nothing we can change here.
The problem with auto fixing this at the moment is that there seems to be a bug within WME.
If you manually delete that node, you’ll notice that sometimes the directionality is correct, and sometimes it is not. This can (and has for me) mean that you have a chunk of unuseable one-way because it is pointing the wrong direction.
You don’t want Toolbox to auto fix this (along with who knows how many others on the screen) unless it could be known that it will certainly point in the correct direction.
i’m not referring to the driving direction. both segments can be 2-way.
it is just that all segments have an A and a B node. If 2 similar segments are connected, both by the A node, or both by the B node, toolbox doesn’t remove the node.
i’ll search for an example…
Yes, bug confirmed. Tb does not remove the node, if the 2 segments are connected by both A or B nodes, and they are oneway in a consecutive direction (i.e. the oneway arrows point in the same direction, if you look at the segments).
That’s an easy one. We’ll fix it.
I would definitely agree with this. A while back, I was doing clean up near a freeway and noticed that two segments of freeway were joined by an unneeded junction node. They had exactly the same properties, were (obviously) both going in the same direction, same elevation, etc. So I deleted the node.
As I continued to work, I suddenly noticed that both the eastbound and westbound lanes had arrows on them showing the exact same direction - the direction of the freeway where I had removed the junction node had reversed. (Yikes!) If that had gotten into a map tile update… :shock:
Since then, I’ve always been extra careful to watch for a directional change on any one-way road segment when getting rid of an unneeded junction node. If I had been using an automatic “delete unneeded junction node” function of a tool, it would have greatly increased the chances that I could have missed that.
Of course, I’m sure I would then notice when the area lit up like a X-Mas tree with URs complaining that they were routed through back-roads in the mountains instead of using the perfectly good freeway… 
Please make sure that when you that, it checks to make sure the direction of a one-way didn’t get reversed…
Please also make sure that any TBTRs on one direction don’t get flipped to be on the wrong direction (which then hides then from the edit restrictions frame).
To clarify if a one way B>A segment has a travel restriction set B>A, and the the nodes get flipped so the direction of the road is A>B but the TBTR stays as B>A it will be hidden from editing in WME, and won’t be applying the restriction times.
Sent using Tapatalk for Android 4.4.2
(I’m assuming you mean time-based segment restriction, not TBTR (time-based turn restriction))
IIRC, the 1.4.6.2 code now checks for any TBR and then refuses to automatically delete the junction node if they are there… regardless of whether they are the same or different.
Yes I was think of time based Travel restriction, but TBSR makes sense to differentiate it.
Ok then this is a non issue if that is the case.
Sent using Tapatalk for Android 4.4.2
Then you have nothing to worry about (unless bgodette’s code was changed).
bgodette’s segment simplifier ignores geometry nodes within a certain distance of segment endpoints for this very reason.
It was tweaked very slightly – the simplify(0.5) was leaving far too many in rounded curve areas, but after experimentation, I settled on 0.8. I didn’t change any of the other code.
EDIT: oh yeah, the other change is that it stops when the edit count hits 100, and follows standard TB integration with that edit count monitoring. It alerts in the same way TB does, rather than the method used by the original (which also wouldn’t stop at 150, but would only do 150 for each of the executions of the bookmarklet)