que01
93f09e399e
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>
72 lines
4.1 KiB
Markdown
72 lines
4.1 KiB
Markdown
# JunctionTools 专用路口编辑工作区
|
||
|
||
## 结论
|
||
|
||
路口应从主地图的上下文控制柄升级为专用编辑工作区。主地图负责发现、选择和进入；`JunctionTools` 负责高密度的局部几何、拓扑和诊断操作。这不改变“OSM 中心线/拓扑只读”和“约束驱动派生输出”的原则。
|
||
|
||
## 入口与范围
|
||
|
||
从路口面或诊断进入，路由参数使用语义引用：
|
||
|
||
```ts
|
||
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、路口边界、步行带、停止线、斑马线和标线必须一起重算。
|
||
|
||
```text
|
||
JunctionTools 草稿操作
|
||
-> 客户端即时 ghost
|
||
-> 防抖服务端局部 junction solve
|
||
-> 返回 fit 后的 junction plan、派生 GeoJSON、拓扑诊断
|
||
-> 当前编辑器局部刷新；返回主地图后复用同一 preview
|
||
```
|
||
|
||
局部解必须校验最小车道宽、连接线包含性、surface 自交、控制设施可放置性与 cluster arm 连续性。无法拟合时返回最后有效几何与结构化诊断；不能把不合法的图形显示成已应用。
|
||
|
||
## 与 revision 的关系
|
||
|
||
`JunctionTools` 的草稿属于活动工作副本的 `EditSession`，不是独立导出文件。用户可以取消并丢弃草稿，或将有效操作合并到主工作区；之后仍通过普通保存和命名检查点进入 revision 历史。
|
||
|
||
## 预览与提交状态
|
||
|
||
“预览”“应用”“保存”是三个不同状态，不能把保存当作看见效果的前提：
|
||
|
||
```text
|
||
首次拖拽 -> 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 优先于道路 profile，solver 在边界自动求连续过渡。
|
||
|
||
## 当前阶段的延后边界
|
||
|
||
`JunctionTools` 会成为核心竞争力，但当前任务只设计其对象边界、会话、预览和约束合同。高级复合路口模板、多个路口联动编辑、控制设施的单对象创作、协作与全面拓扑创作均延后，避免这些问题遮蔽直接编辑基础链路的验证。
|