drawtonomy vs 手写 OpenSCENARIO XML

手写 OpenSCENARIO XML

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

XML 是合适路径的情况：

场景较小，你想要字节级控制。
你通过 DSL 或代码生成流水线以编程方式生成 XML。
你需要可视化工具无法表达的规范特性——条件触发、参数扫描、自定义控制器、复杂 Storyboard、交通流模型。
你通过 git 协作编写场景，稳定的 XML diff 很重要。

对于生产场景编写，手写或代码生成的 XML 是规范方式。

drawtonomy 目前能表达什么

OpenSCENARIO 1.3 的一个子集，根据导出器文档：

2D 俯视路网——车道、路口、简单线串——导出为部分 OpenDRIVE 1.8 .xodr。
车辆、行人、交通灯、道路标线作为 <ScenarioObject> / <Pedestrian> 条目的静态放置。
简单路径/轨迹以 <FollowTrajectoryAction> 形式导出。

导出的 .xosc 可以在 esmini 中回放简单场景。这是一个起点，而非成品场景。

drawtonomy 不能表达什么

在导出器文档中记录为路线图项目：

OpenDRIVE 路口生成（<junction>）。
<signal> 形式的交通标志。
加速/减速曲线、停留/停止事件、感知信号路径、变道动作、多参与者 Storyboard。
条件触发、参数扫描、自定义或基于 ML 的控制器、密集交通流。

对于这些内容，你需要手写 XML 或从代码生成。

合理的混合使用方式

在 drawtonomy 中草绘布局，确定车道网络和参与者放置。
导出 esmini 包并确认简单版本可以回放。
用文本编辑器打开 .xosc，添加 drawtonomy 无法表达的部分。
将 drawtonomy 源文件作为测试计划/论文/幻灯片的配图保留。

drawtonomy 是草图。XML 是任何非平凡场景的真值来源。

同一 OpenSCENARIO 社区

手写 XML 是 OpenSCENARIO 的基础编写路径——生态系统中的所有其他工具最终都会生成它（或其 DSL 等价物）。drawtonomy 的导出器、scenariogeneration、Scenic、RoadRunner、Blender DSC 等都在某个时刻生成 XML。直接读写 XML 是标准保持为标准的方式，而生成它的工具受益于社区围绕它建立的跨工具互操作性。