drawtonomy vs 手写 OpenSCENARIO XML

手写 OpenSCENARIO XML

手写 OpenSCENARIO XML 是一种常见的工作流，在很多场景下也是正确的选择。

以下情况适合直接写 XML：

场景很小，你想要字节级的精确控制。
你通过 DSL 或代码生成流水线以编程方式产出 XML。
你需要 drawtonomy 目前还无法导出的规范特性——参数扫描、自定义 / ML 控制器、密集交通流模型、OpenSCENARIO 1.3。
你要从零搭建带路口的新路网，且需要生产级精度的 <junction> 几何：drawtonomy 在原样导入未经编辑的 .xodr 并重新导出时，路口精度很高；但从手绘车道生成全新的路口几何，目前精度还不够。
你在 git 上维护一个大型场景库，需要稳定的字节级 XML diff。

在这些场景下，手写或代码生成的 XML 是规范路径。但如果只是编写并运行单个具体场景——动作、触发条件、一个 PASS / FAIL 判定——可视化编辑器通常更快。

drawtonomy 目前能表达什么

一个面向 OpenSCENARIO 1.2 的可视化编辑器，可以在画布上搭建完整的 storyboard 并直接在浏览器中运行——全程无需手写 XML：

2D 俯视路网——车道、交叉口、折线——导出为 OpenDRIVE 1.8 .xodr，并可在其上放置车辆、行人、交通灯、道路标线等实体。
完整的 storyboard：阶段（act）、事件、规范中全部 35 种动作（速度、变道、瞬移、轨迹跟随、激活控制器等），以及全部 19 种触发条件（另加 6 种进阶条件），可通过 AND / OR 逻辑组合。
END 与 FAIL 条件，场景运行结束后给出 PASS / FAIL 判定。
基于编译为 WebAssembly 的 esmini 在浏览器内直接执行——播放控制、逐帧精确定位（seek）、跟随相机、幽灵轨迹（ghost trail），以及可选的 3D 预览，让你无需离开页面即可查看场景运行效果。导出的 .xosc 同样可以在原生 esmini 环境中不加修改地运行。
可导出为 OpenSCENARIO 1.0、1.1 或 1.2（1.3 暂不支持导出），并支持导出 OpenDRIVE 的 <junction> / <connection> 图元，以及以 <signal> 形式导出的交通标志。

drawtonomy 目前还不能表达什么

以下是目前确实存在的差距，仍需要手写或代码生成 XML 来补足：

OpenSCENARIO 1.3 导出——该格式已支持导入，但尚未作为导出目标提供。
从零搭建路网时的生产级 OpenDRIVE <junction> 几何。若是原样导入未经编辑的 .xodr 再导出，路口连接关系可以精确往返；但从手绘车道生成全新的路口几何，目前精度仍然不足，也尚未建模解析式缓和曲线（clothoid）几何。
参数扫描、自定义或 ML 驱动的控制器，以及密集交通流模型。
OpenSCENARIO 2.0 / M-SDL（drawtonomy 目前面向 1.x 版本）。

对于这些需求，手写或代码生成 XML 仍是正确的路径。

一种合理的混合用法

对于绝大多数完全在 drawtonomy 中编写并运行的场景，浏览器就是唯一真值来源（source of truth）。只在边缘情况下才需要手写 XML：

在 drawtonomy 中搭建场景和 storyboard——车道网络、参与者、动作、触发条件、结束 / 失败条件——运行一次以确认判定结果。
如果你需要 drawtonomy 还无法导出的规范特性（某个路口图元、参数扫描、自定义控制器），导出 .xosc 后手动编辑或用代码生成补上那一部分。
如果你需要在大型场景库中维护字节级的 git diff，把规范版本的 XML 保留在代码仓库中，用 drawtonomy 来编写、审阅、回放单个具体场景。

drawtonomy 负责编写和运行场景；手写 XML 仍是应对它尚未覆盖的规范细节的补充手段。

同属一个 OpenSCENARIO 生态

手写 XML 是 OpenSCENARIO 生态中最基础的编写路径——生态系统里的其他工具最终都会产出它（或其 DSL 等价物）。drawtonomy 的导出器、scenariogeneration、Scenic、RoadRunner、Blender DSC 等，都会在某个环节产出这份 XML。直接读写 XML 是这个标准之所以能保持为“标准”的原因，而生产它的工具也因此获益于社区围绕它建立起来的跨工具互操作性。