junction corners: curved approaches produce colliding corner geometry (straight-ray solver)

[JArmandoAnaya]

From the 2026-07 field triage (item 4, screenshot 3). Diagnosed against main @ 950939c.

Where a curved road meets a junction, the corner geometry collides/overlaps in the render — boundary interpenetration near the curve.

Root cause — straight-ray corner solver. corner_faces() samples each approach arm at a single end station and treats its outer edge as an infinite straight ray (core/src/mesh/junction_corner_detail.cpp:130-186, ray at :148-149); solve_corner() intersects those straight rays (:203-211); append_corner_fillets extends straight edge strips (core/src/mesh/junction_surface.cpp:143-188). When the approach curves near the mouth, the true pavement edge diverges from the ray and the fillet/strip/wedge geometry interpenetrates the road's own footprint. Connecting-road footprints, by contrast, sample per station and are curvature-safe (core/src/mesh/fill_backend.hpp:109-138).

Not the p4-s5 escape-valve artifact class: surface spans arbitrate elevation/samples inside a fixed union and can never move the boundary (junction.hpp:132-137; the realignment doc rules out new triangulation algorithms for spans). This is a generation bug in merged p4-s1/s2-era code.

Scope

• Corner solving samples the true curved pavement edge near the junction mouth instead of a single-station straight ray: corner_faces / solve_corner (core/src/mesh/junction_corner_detail.cpp:130-273) and the straight edge strips + wedge apex in append_corner_fillets (core/src/mesh/junction_surface.cpp:143-188).
• The Corner tool handles follow automatically (junction_corners() drives them from the same solver, core/src/road/junction_corners.cpp:48).

Refactorings

• None planned; keep the solver shared between mesher and query (byte-identity guards: verbatim arc sampling junction_corner_detail.cpp:311-337, arms≥2 round-trip rule :132-137).

Acceptance

• Screenshot-3 reproduction: a curved road meeting a junction of sidewalked roads → no interpenetrating corner geometry; boundary edges follow the curved pavement edge.
• Straight-approach junctions unchanged (byte-identical output or visually identical + tests green) before/after.
• Regression surface green: p4-s1 corner edits (radius/extents ops operations.cpp:3782,3821), p4-s2 wedges/noses (junction_surface.cpp:752-844), p4-s5 spans (junction_surface_spans.cpp), p4-s4 lock/regen record-carry, p4-s6 maneuver-shaped connecting roads. Sanitizer run mandatory (P4 discovery risk note), covering the editor tests too.

Out of scope

• Sidewalk wrap generation and mixed-boundary handling (junction corners: continuous sidewalk wrap + mixed sidewalk/no-sidewalk boundary #357).
• Span/sort-index semantics.

Supersedes

(none — successor of the #103/#105 T-junction-quality lineage.)

[JArmandoAnaya]

The 2026-07 field-triage fix queue (#352 → #356 → #354 → #357 → #358 → #355) has landed its four CI-verifiable fixes: #352 (teardrop-loop), #358 (cursor-anchored zoom), #354 (multi-crossing/T in one command), #355 (urban-sidewalks default) — all merged to main.

#356 and #357 are deferred from the automated run: their acceptance is a visual junction-corner render (screenshots 2–3), which can only be asserted headlessly as watertightness + byte-identity — not that the corners look right — and they touch the byte-identity-guarded junction mesher. They are held for a focused maintainer-in-the-loop session with visual verification. #357 still lands after #356.

[JArmandoAnaya]

Deferred pending a field repro — investigation findings (2026-07-22)

A focused implementation attempt against main @ 15f63ab concluded that the prescribed fix cannot ship as specified, and the reported corner interpenetration does not reproduce in the headless mesh harness. The kernel was left byte-identical to HEAD (no code change). Details so the eventual fix is well-scoped:

1. The tangent-leg clamp is mathematically self-defeating

Implementing the multi-station edge walk + clamping max_extent_a/b by edge/ray divergence: once the clamp actually engages it shrinks the derived r30 fillet radius and regresses FilletedBoundaryIsSmoothAndRadiused (test_t_junction_quality.cpp) for r30_outside (max concave turn 25.06°) and r30_inside (32.23°) against the < 20° gate — a smaller fillet at the fixed kFilletArcSagitta plus the kFilletTangentLift shortcut yields a sharp per-vertex concave turn. The divergence tolerance cannot separate good geometry from a "bug" case: keeping the r30 corner-1 fillet unclamped needs tol ≥ 0.49 m, but at that tolerance the clamp no longer bites (max_radius stays above the derived radius, so radius = min(derived, max_radius) is unchanged). Any tolerance small enough to clamp regresses; any large enough not to regress is a no-op.

2. The strip change is provably vacuous

The corner edge strip / wedge is folded into the connecting-road footprint Clipper union. Capping the curved-arm strip at the tangency instead of the far ray-apex leaves the emitted floor byte-identical (floor_area identical old-vs-new across every scenario: T-through curved r30 in/out; create_junction curved arm at r = 10/20/30). The [tangency → apex] segment is always already covered by the wedge, so the union never changes.

3. The interpenetration does not reproduce headlessly

Every curved sidewalked junction built (urban_sidewalk profile, through-target and ending-arm topologies, r = 10/20/30) is watertight, 0 boundary self-intersections, 0% floor-vs-arm plan overlap (floor-triangle centroids checked against all arm lane-patch triangles, sidewalks included). Both of this issue's acceptance criteria ("no interpenetrating corner geometry", "boundary edges follow the curved pavement edge") already hold at the mesh level. The corner-solver code is unchanged since the diagnosed commit (git log 950939c..HEAD on junction_corner_detail.cpp / junction_surface.cpp shows only the Apache relicense), so this is not "already fixed by intervening work" — the constructed repro geometry simply is not hitting the field artifact.

What is needed to proceed

• The field repro geometry — the screenshot-3 .xodr (or an esmini/.glb dump via RM_TJ_DIAG_DIR). Without a case that actually interpenetrates in the harness, no fix can be written or verified.
• A real fix is likely a curved-edge-aware corner — fillet tangent to the actual sampled pavement curves rather than to straight tangent-line rays (for the r30 cases the straight rays meet at a fabricated apex 8–26 m out). This is a solver redesign, and per the analysis it will not be verifiable through the current byte-identity / watertight harness — it must be validated visually. Because of that, it cannot be "auto-merged on green"; it needs a maintainer-in-the-loop visual session.

Ready-made regression coverage for the redesign

The investigation produced a reusable setup_curved(double r, bool inside, const LaneProfile& profile = two_lane_rural()) overload and r30_sidewalk_outside / r30_sidewalk_inside TeeCase entries (a curved road meeting a junction of sidewalked roads — this issue's exact scenario). These were intentionally not landed with the #357 sidewalk-wrap PR: adding sidewalk profiles to the shared TJunctionQuality matrix makes the FloorCarriesDrivingMaterial TEST_P fire on a now-segmented (carriageway + sidewalk-band) floor, which needs relaxing to per-region material. Land these cases with the redesign so both changes are tested together.