tonytx05 wrote:

SeveriorumPatrem wrote:I've been working in rural areas and merging unnecessarily segmented runs of roads. Every time I "bridge" the segments together, the elevation is bumped up one position. Then have to re-select road, click elevation dropdown, select "Ground", save.... would love a one-click elevation reset tool.

Why don't you just delete the unnecessary node instead of using the bridge tool?

This does not always work.
Same with the "Suppress Unneeded Junctions" function.
Yes, if the speed limits are not the same, or confirmed/unconfirmed, these functions will not work, but I have had many instances where neither the TB function nor manually deleting the node will work, even after verifying that every detail on both segments is a 100% match.
The bridge tool works in these cases (but bumps the elevation by 1)

But I would agree that adding a "level" function may not be the best idea. Many times wayfinding stubs that are tucked in tight are set to "-" elevations to hide them from display and to prevent issues with the disconnected junction.
These are nearly always very well hidden and not visible at any zoom level wider than 10.

I would be less opposed to a function that lowers all positive elevation values to "ground" since these are generally only used for segments that actually cross.

juankx wrote:

taco909 wrote:[but I have had many instances where neither the TB function nor manually deleting the node will work, even after verifying that every detail on both segments is a 100% match.
The bridge tool works in these cases (but bumps the elevation by 1)

That happens when A > B don't match... There was a bug that changes the road direction when you delete a node, it seems that this was fixed avoiding the node removing when there is a A-A or B-B connection.

I've even had this happen when there is a match, but yes, it absolutely won't work if A-B don't match, I have not tried the Bridge function in these cases.

starkreiten wrote:Howdy, I'm not sure if this is the right place to post, but I figured somebody here already knows the answer.

What happend is that I stumbled across a 4-way intersection that had two sets of paired 'quartering' segments joined, with the overlapping JNs so well placed that until I 'pulled' one of the JNs and it's 'pair' off, I couldn't tell what was going on.

So, does a script for detecting overlapping JNs exist... or is it even possible?

Seems like something I'd like to 'monitor' with toolbox like revcons and dead-ends and such.

Thanks!
-Dana

Overlapping junctions, or micro-doglegs (geonodes very close to the junction) used to "tuck" a segment in to another to hide it?

If you have two junctions within 5m of each other, Validator will flag the segment as too short.
I'm not sure that there is a way to detect micro-doglegs other than being careful when adjusting geometry... also ensuring that "unusual" configurations are locked higher than normal to avoid inexperienced editors disturbing them. Hopefully, if an unlock is requested, the unlocking editor will look closely to see just why the area was uplocked.

Ahh... And because both junctions have two or more segments attached, Validator does not flag the disconnection. Makes sense.

starkreiten wrote:Thanks for the input everyone. My rusty old gears are starting to squeak again...

The tool I'm envisioning would highlight any junction that is within 5m of any other junction -- maybe with a little red circle that would just happen to fit around a soft-turn's cute yellow dot.

If nothing else, it will give me an excuse to dabble my toes into WME scripting.

-Dana

I agree.

Junctions that closely spaced are rare enough that they should be called to attention.

Must be a glitch on the ROTW server. I just tried it and was unable to save the edit.

The problem is that the majority of Firefox users won't be running the developer edition, nor a nightly. They'll run the stable version, where that check won't be possible to disable from 42 onwards.

The best way to solve that is obviously to sign the extension. There's two ways to do that, though they both involve uploading it to AMO, either publicly or unlisted.

If it's made public on AMO, it's automatically signed when it's published, meaning users grabbing it there will get a signed version. This also has the advantage that new users can install it from there instead of externally.

If it's unlisted, then the XPI has to be uploaded to AMO, and if it passes the automatic validation, you get back a signed XPI that you can then put anywhere for people to download. This has the downside that each time there's a new version, the dev team will to upload it, grab back the signed version and upload it somewhere else.

(I doubt the extension will fail the automatic validation since it doesn't do anything with the browser itself.)

The third, less elegant option, would be to provide Toolbox as a userscript, since those don't have to be signed. But I don't know if Toolbox is still available as a userscript or if it has evolved past that.

Suppressing Nodes is still broken for me (has been for what feels like a week). @wrocco we can't add more than one entry/exit point for places yet, and still can't name them. It's just the base UI with extremely limited functionality at this point. Everything else in TB that I use (including clear geometry) seems to still be working.

beliamuda wrote:
Unfortunately, after re-launch Chrome, Toolbox become corrupted again.

I had the same thing happen to me. I had to delete all extensions, and add them back. Since then everything has been running well. I even noticed some petty annoyances have disappeared.

juliansean wrote:
Even after restarting Chrome toolbox stays fixed tcalvert???

So no more Toolbox issues, even after you relaunch Chrome?

With much fear and trepidition, I've had issues, not even when after relaunching Chrome....



Sent from my iPhone using Tapatalk