feat: drag road handles with ghost and server preview

Three things, kept in one commit because they touch overlapping hunks of the
same two files and this environment has no interactive hunk staging. Splitting
them by file would have drawn boundaries that misrepresent what changed.

1. Step 4 of the map editor. A native OpenLayers PointerInteraction turns a
   drag into a clamped constraint value, the ghost source shows it immediately,
   and the solver's answer replaces a parallel set of preview layers while the
   baseline layers are hidden rather than overwritten. Preview requests debounce
   at 80 ms, pointerup flushes without waiting, and a newer request aborts the
   one in flight; EditSession decides which answers count. Handle positions come
   from the clamped value, so a handle stops at its limit instead of following
   the cursor. Three of the four drag capabilities are live: edge offset,
   sidewalk width, lane divider.

2. Road edge handles were drawn on the wrong side. offsetLine() offsets
   counter-clockwise from the direction of travel and sidewalks use
   `heading + (side === 'left' ? -90 : 90)`, so left is `tangent - 90`;
   makeRoadHandles() placed the left handle at `tangent + 90`, over the right
   kerb. Dragging the visually-left handle moved the right edge. Fixed on both
   sides of the wire, with regression tests that name the sides geographically
   rather than by axis sign.

3. Roads the junctions geometrically fill are now read-only. The 0.45 cap per
   reserve made the existing `unavailable` branch unreachable, so a 14.5 m stub
   between two junctions was offered a 1.5 m editable band with no room for the
   transitions a road-interval constraint needs. Greying only affects the
   manifest: constraints already saved against such a road keep being solved, so
   the geometry output is unchanged and the fixture baselines do not move.

Range handles are built and unit-tested but hidden behind
`intervalEditingSupported`: compileGeometry() reads neither profile.interval nor
profile.transitions, so every edit applies to the whole road and the control
would have had no effect. Recorded in research/interval-not-applied.md, which
also blocks one PRD acceptance criterion.

The ol-ext probe stays in the tree as a manual harness; ol-ext is still not a
dependency.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-27 17:38:34 +08:00
parent bc4b9a9717
commit 92297270f1
25 changed files with 1826 additions and 58 deletions

View File

@@ -0,0 +1,68 @@
# 实施计划
轻量任务,一个提交即可。门禁不过就停。
前置:无。客户端置灰渲染路径已由 `08-26-direct-edit-map-editor` 第 3 步交付并有单测覆盖,
本任务只补服务端输入。
## 关键决定:置灰只影响手柄,不影响求解
`editable: false` 只改变 handle manifest**不改变 `solveConstraints()` 的行为**。
落在被置灰 segment 上的既有约束仍然照常应用、照常参与几何编译。
理由:否则本次改动会让升级后的编译静默丢掉用户已保存的编辑——一个 UI 可编辑性的判断
不该回溯否决已持久化的意图。用户想撤销这类编辑,走 undo / 禁用约束的正常路径。
这也让「几何输出逐字节不变」这条验收标准成立,从而使本步骤可安全回滚。
## 1. 判据与置灰
- 目标:可编辑带短于道路宽度的 segment其全部 `road-*` 手柄 `editable: false`
- 位置:`src/compile/direct-edit-solver.js``makeRoadHandles()`
该函数已算出 `start` / `end` / `length` / `width`,判据是纯本地计算,不需要新数据。
- 实现要点:
- 带长米数 `(end - start) * length`,与 `width`(该 segment 双向宽度之和)比较。
- 复用既有 `baseDisabled` 机制与既有文案「该道路全部位于路口保留区,请进入 JunctionTools 编辑。」,
不新增第二套提示语。
- 保留原 `unavailable` 判断作为兜底,两者取或。
- 被置灰的 segment 仍然产出手柄(位置照旧),只是 `editable: false` 且带 `disabledReason`
- 不改:`junctionReserves()` 的 0.45 上限、cutback 推导、`solveConstraints()`、junction 手柄。
## 2. 测试
- 位置:`test/direct-edit-solver.js`
- 覆盖:
- 短路段(带长 < 宽度)的全部 `road-*` 手柄 `editable: false``disabledReason` 非空。
- 正常路段 `editable: true` 且无 `disabledReason`
- 判据边界:带长略小于 / 略大于宽度两侧各一例。
- junction 手柄仍 `editable: true`
- 置灰 segment 上的既有约束仍被求解(`constraintStates``applied: true`
证明置灰没有回溯否决已保存编辑。
## 3. 验证
```bash
npm run test # 含 test/direct-edit-solver.js
npm run test:client # 客户端类型
npm run test:client:unit # 客户端纯逻辑
npm run format:check
npm run build
```
几何不变的实测(本任务的核心安全性证明):对 `test/fixtures/fengshu-er-road.osm`
在改动前后各跑一次 `compileGeometry`,比较全部输出图层的 JSON必须完全一致。
`npm run test` 里的 fixture 基线测试已覆盖这条,若基线有 diff 即为回归。
手测(可选,`directEdit` 开关打开):选中 `test/fixtures` 里那 6 段短路之一,
应看到灰色手柄且 header 显示原因。这是父任务 prd 那条验收标准第一次真正可演示。
## 4. 门禁
- 几何输出零变化fixture 基线无 diff
- 正常路段行为与当前 main 完全一致。
- 既有约束不因置灰而失效。
## 回滚点
单文件单函数改动,`git revert` 即可回到当前行为。
客户端不需要任何配合改动,回滚后灰色手柄自然消失,回到「空真」状态。