Description
Accepting connected Rapid/Overture road features can delete the endpoint shared by the accepted ways.
The failure happens in actionRapidAcceptFeature() when auto-connect handles an accepted way endpoint that is already the same node as the target merge node. In that case bestResult.mergeNodeId === node.id, but the merge branch still treats the original endpoint as orphaned and removes it from the graph. That leaves the previously accepted connected way referencing a node that no longer exists.
This appears to have been introduced by PR #1769, specifically commit 9a2e029087de9903291e9b20431cbcc75c611008 (Auto connect new ways, inherit classification). That commit added the endpoint auto-connect logic and the unconditional graph.remove(node) in the bestResult.mergeNodeId path.
Steps to reproduce
A reduced reproduction:
- Accept a Rapid/Overture road way with nodes
n-27 -> n-28.
- Accept a second Rapid/Overture road way with nodes
n-28 -> n-29, where n-28 is the same endpoint node already used by the first accepted way.
- During endpoint auto-connect for the second way, the spatial tree can return the first accepted way as the target way and
n-28 as the best merge node.
- Because the merge node is the same node as the endpoint being processed, replacing endpoint references is a no-op, but the code still removes
n-28 as though it were an orphaned duplicate.
Expected behavior
The shared endpoint should remain in the graph, and both accepted ways should continue to reference it:
- first way:
n-27 -> n-28
- second way:
n-28 -> n-29
Actual behavior
The shared endpoint n-28 is removed from the graph after accepting the second way, leaving the first accepted way with a missing child node.
Notes
The fix should skip the duplicate-node removal when bestResult.mergeNodeId is equal to the endpoint node's own ID. The original removal behavior is still correct when the accepted endpoint is a distinct duplicate node being merged into an existing OSM node.
Description
Accepting connected Rapid/Overture road features can delete the endpoint shared by the accepted ways.
The failure happens in
actionRapidAcceptFeature()when auto-connect handles an accepted way endpoint that is already the same node as the target merge node. In that casebestResult.mergeNodeId === node.id, but the merge branch still treats the original endpoint as orphaned and removes it from the graph. That leaves the previously accepted connected way referencing a node that no longer exists.This appears to have been introduced by PR #1769, specifically commit
9a2e029087de9903291e9b20431cbcc75c611008(Auto connect new ways, inherit classification). That commit added the endpoint auto-connect logic and the unconditionalgraph.remove(node)in thebestResult.mergeNodeIdpath.Steps to reproduce
A reduced reproduction:
n-27 -> n-28.n-28 -> n-29, wheren-28is the same endpoint node already used by the first accepted way.n-28as the best merge node.n-28as though it were an orphaned duplicate.Expected behavior
The shared endpoint should remain in the graph, and both accepted ways should continue to reference it:
n-27 -> n-28n-28 -> n-29Actual behavior
The shared endpoint
n-28is removed from the graph after accepting the second way, leaving the first accepted way with a missing child node.Notes
The fix should skip the duplicate-node removal when
bestResult.mergeNodeIdis equal to the endpoint node's own ID. The original removal behavior is still correct when the accepted endpoint is a distinct duplicate node being merged into an existing OSM node.