drawtonomy vs OpenSCENARIO XML escrito a mano

XML de OpenSCENARIO escrito a mano

Escribir a mano el XML de OpenSCENARIO es un flujo de trabajo habitual y, para muchos casos de uso, el más adecuado.

Cuándo el XML es el camino correcto:

• El escenario es pequeño y quieres control a nivel de byte.
• Generas el XML de forma programática desde un DSL o un pipeline de codegen.
• Necesitas funciones de la especificación que drawtonomy no emite — barridos de parámetros, controladores personalizados o impulsados por ML, modelos densos de flujo de tráfico, OpenSCENARIO 1.3.
• Estás construyendo una red vial nueva con cruces desde cero y necesitas geometría <junction> de calidad productiva — la exportación de cruces de drawtonomy es precisa cuando arrastra un .xodr importado sin editar, pero generar geometría de cruce nueva a partir de carriles dibujados a mano todavía tiene poca precisión.
• Colaboras en un catálogo grande vía git y te importan los diffs estables a nivel de byte del XML.

Para esos casos, el XML escrito a mano o generado por código es el enfoque canónico. Para crear y ejecutar un único escenario concreto — acciones, triggers y un veredicto PASS / FAIL — un editor visual suele ser más rápido.

Qué puede expresar drawtonomy hoy

Un editor visual para OpenSCENARIO 1.2 que crea un storyboard completo en el lienzo y lo ejecuta en el navegador — sin escribir XML:

• Una red vial 2D en vista cenital — carriles, intersecciones, linestrings — exportada como .xodr de OpenDRIVE 1.8, más la colocación de vehículos, peatones, semáforos y marcas viales como entidades.
• Un storyboard completo: fases (actos), eventos, las 35 acciones de la especificación (velocidad, cambio de carril, teletransporte, seguimiento de trayectoria, activación de controlador y más), y las 19 condiciones de disparo (más 6 avanzadas), combinables con lógica AND / OR.
• Condiciones END y FAIL que producen un veredicto PASS / FAIL al ejecutar el escenario.
• Ejecución en el navegador sobre esmini compilado a WebAssembly — controles de transporte, búsqueda temporal precisa al fotograma, cámara de seguimiento, estelas fantasma y una vista previa 3D opcional de la reproducción — para revisar el escenario en ejecución sin salir de la página. El .xosc también se ejecuta sin cambios en una instalación nativa de esmini.
• Exportación a OpenSCENARIO 1.0, 1.1 o 1.2 (1.3 todavía no está disponible), además de primitivas <junction>/<connection> de OpenDRIVE y señales de tráfico como entradas <signal>.

Qué no expresa drawtonomy

Las carencias genuinas que todavía requieren XML escrito a mano o generado:

• Exportación a OpenSCENARIO 1.3 — el formato se soporta en la importación, pero aún no se ofrece como destino de exportación.
• Geometría <junction> de OpenDRIVE con calidad productiva al construir una red vial desde cero. La conectividad de cruces se conserva con precisión cuando arrastra un .xodr importado sin editar; generar geometría de cruce nueva a partir de carriles dibujados a mano todavía tiene poca precisión, y la geometría analítica de clotoide no se modela.
• Barridos de parámetros, controladores personalizados o impulsados por ML, y modelos densos de flujo de tráfico.
• OpenSCENARIO 2.0 / M-SDL (drawtonomy apunta a 1.x).

Para esos casos, escribir o generar el XML sigue siendo el camino correcto.

Un híbrido razonable

Para la mayoría de los escenarios que creas y ejecutas por completo en drawtonomy, el navegador es la fuente de verdad. Recurre al XML escrito a mano solo en los bordes:

1. Crea la escena y el storyboard en drawtonomy — red de carriles, participantes, acciones, triggers, condiciones de fin/fallo — y ejecútalo para confirmar el veredicto.
2. Si necesitas una función de la especificación que drawtonomy no emite (una primitiva de cruce, un barrido de parámetros, un controlador personalizado), exporta el .xosc y edita a mano o genera por código esa parte concreta.
3. Cuando quieras diffs de git a nivel de byte en un catálogo grande, mantén el XML canónico en código y usa drawtonomy para crear, revisar y reproducir escenarios concretos individuales.

drawtonomy es donde creas y ejecutas el escenario; el XML escrito a mano sigue siendo la vía de escape para los rincones de la especificación a los que todavía no llega.

En la misma comunidad de OpenSCENARIO

El XML escrito a mano es la vía de autoría fundacional de OpenSCENARIO — todas las demás herramientas del ecosistema acaban produciéndolo (o su equivalente en DSL). El exportador de drawtonomy, scenariogeneration, Scenic, RoadRunner, Blender DSC y el resto emiten el XML en algún punto. Leer y escribir el XML directamente es lo que mantiene el estándar como estándar, y las herramientas que lo producen se benefician de la interoperabilidad entre herramientas que la comunidad ha construido a su alrededor.

Lecturas relacionadas

• Editor de escenarios — crea acciones, triggers y condiciones de fin/fallo en el navegador.
• Crea tu primer escenario — un cambio de carril desde un lienzo vacío.
• ¿Qué es OpenSCENARIO?
• Caso de uso: editor OpenSCENARIO
• Exportar a ASAM OpenDRIVE / OpenSCENARIO