Files
road-compiler/.trellis/tasks/08-26-direct-manipulation-road-editor/research/junction-tools.md
que01 93f09e399e chore(road-editor): plan direct-edit task tree and add client test infra
Planning: parent design.md becomes the single authoritative contract
(constraint model with 6 kinds, handle manifest, coordinate/unit
layering, preview sequencing, storage layout and lazy migration, area
config snapshot, API contract). Work is split into four independently
verifiable child tasks with per-step gates and rollback points.

Test infra: pin vitest 4.1.11, add test:client:unit for client pure
logic, extend prettier globs to root *.ts so vitest.config.ts is checked.

Add .gitignore: the repo had none, so inputs/, outputs/, workbench-data/
and the client build output were untracked rather than ignored.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-26 17:33:42 +08:00

4.1 KiB
Raw Blame History

JunctionTools 专用路口编辑工作区

结论

路口应从主地图的上下文控制柄升级为专用编辑工作区。主地图负责发现、选择和进入;JunctionTools 负责高密度的局部几何、拓扑和诊断操作。这不改变“OSM 中心线/拓扑只读”和“约束驱动派生输出”的原则。

入口与范围

从路口面或诊断进入,路由参数使用语义引用:

type JunctionRef =
  | { type: 'node'; id: string }
  | { type: 'cluster'; id: string }

工作区加载活动 revision 中该 junction 的 context路口面、外部进口、相邻道路的短上下文、车道/connector、步行带、停止线、斑马线、诊断和当前 constraints。保留返回主地图的入口与位置避免用户失去全局方位。

统一 UI、不同求解器

普通 node 和复合 cluster 仍共享“进口、角部、控制设施、诊断”的用户心智模型;但 JunctionTools 根据 JunctionRef 提供不同内部投影:

  • node按 OSM node 的 incoming/outgoing approaches 和 corners 编辑。
  • cluster按对外 arms 编辑;内部短连接不作为用户可拖的普通路口边缘,避免约束彼此冲突。

这比强迫主地图显示一套通用控制柄更可靠,也比暴露多套产品工具更易理解。

快速拓扑拟合与更新

此处“拓扑更新”指重新求解生成道路的可行拓扑,不修改 OSM 图拓扑进口横断面、车道分配、connector/movement、路口边界、步行带、停止线、斑马线和标线必须一起重算。

JunctionTools 草稿操作
  -> 客户端即时 ghost
  -> 防抖服务端局部 junction solve
  -> 返回 fit 后的 junction plan、派生 GeoJSON、拓扑诊断
  -> 当前编辑器局部刷新;返回主地图后复用同一 preview

局部解必须校验最小车道宽、连接线包含性、surface 自交、控制设施可放置性与 cluster arm 连续性。无法拟合时返回最后有效几何与结构化诊断;不能把不合法的图形显示成已应用。

与 revision 的关系

JunctionTools 的草稿属于活动工作副本的 EditSession,不是独立导出文件。用户可以取消并丢弃草稿,或将有效操作合并到主工作区;之后仍通过普通保存和命名检查点进入 revision 历史。

预览与提交状态

“预览”“应用”“保存”是三个不同状态,不能把保存当作看见效果的前提:

首次拖拽 -> session draft + 即时 ghost
防抖服务端返回 -> JunctionTools 显示权威局部几何/诊断预览
应用到工作区 -> 将有效 draft 合并为主工作区的未保存约束;主地图继续显示预览
保存 -> 将活动副本写入持久化文档
保存检查点 -> 冻结为不可变 revision
取消 -> 丢弃未应用的 JunctionTools draft恢复进入前的工作区状态

预览必须包含所有受影响的派生对象道路面、路口面、步行带、车道中心线、connector/movement、停止线、斑马线与标线以及拟合失败时的诊断和最后一个有效结果。

会话边界

一次 JunctionTools 会话严格聚焦一个 JunctionRef。进入相邻路口前,用户必须应用或取消当前草稿;系统不允许两个路口草稿在同一个局部 solver session 内并存。已应用但未保存的编辑属于主工作区,可在主地图的普通 undo/redo 中管理。

与道路编辑的所有权

主地图 road editor 只拥有两个 junction reserve 之间的内部 road interval。路口两端的 reserve 在地图上可见但不可由道路区间 handle 覆盖;JunctionTools 独占 reserve 内的 approach width、transition、cutback 和 corner 约束。对同一进口,显式 junction-approach constraint 优先于道路 profilesolver 在边界自动求连续过渡。

当前阶段的延后边界

JunctionTools 会成为核心竞争力,但当前任务只设计其对象边界、会话、预览和约束合同。高级复合路口模板、多个路口联动编辑、控制设施的单对象创作、协作与全面拓扑创作均延后,避免这些问题遮蔽直接编辑基础链路的验证。