Skip to content
drawtonomy drawtonomy

drawtonomy vs hand-written OpenSCENARIO XML

Hand-written OpenSCENARIO XML

Section titled “Hand-written OpenSCENARIO XML”

Hand-writing OpenSCENARIO XML is a common workflow and for many use cases the right one.

When the XML is the appropriate path:

  • The scenario is small and you want byte-level control.
  • You’re generating XML programmatically from a DSL or codegen pipeline.
  • You need spec features drawtonomy doesn’t emit — parameter sweeps, custom / ML controllers, OpenDRIVE junction primitives, dense traffic-flow models.
  • You’re collaborating on a large catalog via git and stable byte-level XML diffs matter.

For those cases, hand-written or codegen’d XML is the canonical approach. For authoring and running a single concrete scenario — actions, triggers, and a PASS / FAIL verdict — a visual editor is usually faster.

What drawtonomy can express today

Section titled “What drawtonomy can express today”

A visual editor for OpenSCENARIO 1.2 that authors a full storyboard on the canvas and runs it in the browser — no XML typing:

  • A 2D top-down road network — lanes, intersections, linestrings — exported as OpenDRIVE 1.8 .xodr, plus placement of vehicles, pedestrians, traffic lights, and road markings as entities.
  • A complete storyboard: phases (acts), events, 35 actions (speed, lane change, teleport, follow-trajectory, activate-controller, and more), and 19 trigger conditions combined with AND / OR logic.
  • END and FAIL conditions that produce a PASS / FAIL verdict when the scenario runs.
  • In-browser execution on esmini compiled to WebAssembly — transport controls, frame-accurate seek, a follow camera, and ghost trails — so you review the running scenario without leaving the page. The .xosc also runs unchanged in a native esmini install.

What drawtonomy does not express

Section titled “What drawtonomy does not express”

Documented as roadmap items in the exporter docs — the genuine gaps that still call for hand-written or generated XML:

  • OpenDRIVE junction primitives (<junction>) and analytical clothoid geometry.
  • Traffic signs as <signal> entries.
  • Parameter sweeps, custom or ML-driven controllers, and dense traffic-flow models.
  • OpenSCENARIO 2.0 / M-SDL (drawtonomy targets 1.x).

For those, hand-writing or generating XML remains the right path.

A reasonable hybrid

Section titled “A reasonable hybrid”

For most scenarios you author and run entirely in drawtonomy — the browser is the source of truth. Reach for hand-written XML only at the edges:

  1. Author the scene and storyboard in drawtonomy — lane network, participants, actions, triggers, end / fail conditions — and run it to confirm the verdict.
  2. If you need a spec feature drawtonomy doesn’t emit (a junction primitive, a parameter sweep, a custom controller), export the .xosc and hand-edit or codegen that one part.
  3. When you want byte-level git diffs across a large catalog, keep the canonical XML in code and use drawtonomy to author, review, and replay individual concrete scenarios.

drawtonomy is where you author and run the scenario; hand-written XML remains the escape hatch for spec corners it doesn’t yet reach.

In the same OpenSCENARIO community

Section titled “In the same OpenSCENARIO community”

Hand-written XML is the foundational authoring path for OpenSCENARIO — every other tool in the ecosystem ultimately produces it (or its DSL equivalent). drawtonomy’s exporter, scenariogeneration, Scenic, RoadRunner, Blender DSC, and the rest all emit the XML at some point. Reading and writing the XML directly is how the standard stays a standard, and tools that produce it benefit from the cross-tool interoperability the community has built around it.

Section titled “Related reading”