BTW, the simplification factor of 0.8 seems to be performing quite nicely.

It's worth noting that using the 0.5 simplification factor does not touch these stubs. (Great setup, btw.)

Depends how simseg is written.

When Brian posted simseg he warned about releasing the code into the wild because it's easy to change the simplification factor and destroy a bunch of precise segment geometry. I'm going to reinstate my wishes that the Toolbox implementation of this feature should stay at the default factor of 0.5. The script has been tested a lot more at 0.5 than it has at 0.8 or any other factor, and we are already seeing a problem with 0.8.

Sorry, I meant the first line in reply to your previous message, specifically "The length of the line may affect the simplification algorithm."

BTW: the JNF method of fixing single-segment loops (pressing Q) preserves house numbers, but not stop points – you need to nudge any house numbers after doing the fix.

Deleting a dead-end roundabout will not preserve any house numbers.

doctorkb wrote: Fix: Suppress unneeded junctions does not work for all segment connection combinations (#39)

Can you explain this?

My worry is, suppress unneeded junctions should not remove every junction that it is possible to delete in WME. For instance, WME will allow you to delete junctions across elevation changes; suppress unneeded junctions shouldn't do that – sometimes those elevation changes are there for a reason, for instance, when a closure closes only part of a road, an elevation change might be used to ensure that it isn't removed by those tools or highlighted by other tools (Validator). There are other things as well, maybe lock level? Direction?

If I'm just interpreting wrong, that's fine.

BellHouse wrote:Yes, don't worry, we recently added two additional checks, where Tb does not auto-remove nodes: different elevations and present time based restrictions. Issue #39 addressed a Tb bug that nodes were not removed when they were oneway and connected by both A or both B nodes. This was a simple flaw in logic.

I personally don't see a reason why a node should stay just because of different lock-levels?

It's probably most important for closures – when only a small section of a long road is closed, where you might need to get to local addresses (houses, businesses) on either side of the closure – but it's not really a bridge, and there's no real elevation change. You can lock the closure section at a high lock so no one messes with it, including automatic tools.

That said, I don't know if Validator highlights nodes that connect segments identical except for lock level. I know it doesn't highlight nodes if everything but elevation matches, which is good – I use that to my advantage for bridge closures. But it's not always a bridge, so the elevation change is not always accurate...

Arnoniem wrote:You should check a segment for unneeded nodes before applying a closure. Then raise the lock and apply.
You don't need to add a node for closing just half the segment because the street is not open. You can just close the entire segment. In the rare example of adding a node for house number approach or something you could save the added segment to prevent suppress of the unneeded node.
I've had once a similar situation and connected a pedestrian that was near to preserve the node.
So I personally don't see it useful or necessary. But other people might?

Sometimes you do need to add extra nodes for closing. For instance, like I said, a closure of a bridge in the middle of a long segment of highway – there are homes and businesses on that long segment, on either side of the bridge. If you route to one of those homes or businesses, and the closure is on the whole segment, well, either it won't work, or it will think, "there is a closure both ways, so it doesn't matter which way I go." Of course, this is not true at all – it matters very much which way you go, because a bridge is closed from one of the two directions. And, for places on that segment, those are the ones with the most to lose – because it's gonna take the longest to go around to the other side of the closure. These closures are typically in rural areas, where the detours are often many miles long.

Arnoniem wrote:Yes, I understand the issue. But isn't that a rare case, compared to the streets and primaries which have varying L1 and L2 locks?
In the bridge case, you could leave a helper-segment, to prevent node deletion.

A non-known editor could delete the node manually, if he's thinking it might be a heritage from ages ago, when brigdes used to have nodes on both sides. Just my thought

No, I think it's much more likely to have a segment set like this intentionally, with a lock on only some parts. Locks are entirely set by the editor. The only way that a segment would be split up into multiple segments like this: ————•———————•——————— with different locks on different segments, is if an editor locked one of the segments that way.

I don't know what you mean exactly by "helper segment", but I assume it would just look like a base-mapped driveway that was not deleted. Not sure if you've worked in any basemapped countries, but they are full of still-untouched roads with lots of never-deleted driveways and extra nodes. So it's very hard to tell whether that was done on purpose or not – a lock is the only real way to make other editors KNOW that another editor has edited it that way for a reason.

doctorkb wrote:

sketch wrote:a lock is the only real way to make other editors KNOW that another editor has edited it that way for a reason.

And I'm still finding locks left around because that was the only way to not have Waze (app) automatically allow changes in directionality / turn restrictions... so a lock doesn't even indicate that the editor did it a certain way *correctly* -- just that they did it and didn't want the automated processes to update it.

Sure. But that's why we have human editors. At the minimum, an automated script should not mess with it.