ASAM OpenDRIVE (.xodr): the standard — and a ready file from OSM

OpenDRIVE is an XML standard from ASAM e.V. for describing road networks with lane-level detail, used by practically every autonomous-driving simulator on the market. A file with the .xodr extension contains not just road centerlines but a full geometric model: every lane with its width and type, road markings, signs, traffic lights, junctions with topology connections, roadside objects, road surface elevation. The format underpins ADAS test scenarios at BMW, Mercedes-Benz, Audi, Volkswagen, and is the primary import format for CARLA Simulator, IPG CarMaker, dSPACE ASM Traffic, NVIDIA DriveSim. On osm2cdr.ru opendrive_exporter.py turns OSM highway=* tags into an ASAM-compliant .xodr with heuristic upgrade into lanes via lanes=* and width=* tags — a small area (up to 1 km²) exports into a file ready to load in Eclipse esmini for sanity-checking.

History: VIRES 2006 → ASAM 2018 → v1.8 (2024)

OpenDRIVE was born in 2006 inside the German company VIRES Simulationstechnologie GmbH, specializing in automotive simulators. Before it appeared, every simulator used its own proprietary road network format — meaning test scenarios built for VTD (Virtual Test Drive) didn't work in IPG CarMaker, and vice versa. VIRES released OpenDRIVE as an open specification specifically to solve this fragmentation.

Early years saw slow growth — version 1.0 (2006), 1.1 (2008), 1.2 (2010), 1.3 (2013). The real breakthrough came in 2014 when the auto industry started investing heavily in self-driving. BMW, Daimler, Audi and Volkswagen Group officially adopted OpenDRIVE as the standard for ADAS test scenarios. Version 1.4 (2015) expanded lane marking support and enriched signal types.

In 2018 VIRES handed OpenDRIVE ownership to ASAM e.V. (Association for Standardization of Automation and Measuring Systems) — a German non-profit organization focused on automotive electronics standardization. That made OpenDRIVE a formal international standard under industry consortium management of 350+ companies. In parallel ASAM launched OpenSCENARIO (dynamic scenario description — motion trajectories, events) and OpenCRG (high-fidelity road surface for tire simulation), forming a trio of complementary standards.

Version 1.7 (August 2021) added a revised lane model with dynamic objects support and improved signal placement. Version 1.8.1 (2024) refined road object semantics and fixed inconsistencies in junction representation. By 2026 the specification reached 1.9.0 with improved rail and tram track support. Today OpenDRIVE is the de facto industry standard for road geometry in AV simulation, with Eclipse esmini as the reference open-source viewer + runtime.

Inside OpenDRIVE: <OpenDRIVE>, <road>, <lanes>, <signals>, <junction>

An .xodr file is XML with strictly hierarchical structure. The root <OpenDRIVE> element contains header metadata (name, spec version, geo reference) and then a list of <road> and <junction> elements.

<road>. The base unit — a stretch of road between two junctions or to a dead-end. Each road has a unique id, a length, references <predecessor>/<successor> to neighboring roads or junctions. Inside a road the main components are:

• <planView> — horizontal geometry as a sequence of geometric primitives: <line> (straight), <arc> (circular arc), <spiral> (clothoid/Euler spiral — a transition curve with linearly changing curvature), <poly3> (cubic polynomial), <paramPoly3> (parametric cubic). This is the mathematically exact centerline description.
• <elevationProfile> — elevation changes along the road as polynomial functions of arc length.
• <lateralProfile> — superelevation (banking) and shape (cross-slope) — critical for simulation physics on curves.
• <lanes> — laneSections with left/center/right lane groups. Each <lane> has a type (driving, sidewalk, shoulder, parking, biking), width as a polynomial of arc length, lane markings (solid, broken, solid solid).
• <objects> — physical roadside objects: barriers, trees, sign posts, parking lots. Size, position, orientation.
• <signals> — traffic signs and signals (lights). Position along road, lane validity, signal type (e.g. 1000001 for a standard traffic light in the German catalog).

<junction>. An intersection as an explicit topology element. A list of <connection> elements describes all possible paths through the junction: incomingRoad → connectingRoad → outgoingRoad with explicit lane-to-lane mapping. This is critical for path planning in the simulator — the algorithm knows all legal maneuvers at the junction without needing to infer geometry.

Coordinate system. OpenDRIVE uses inertial (world) Cartesian + road-relative (s, t) coordinates, where s is distance along centerline and t is perpendicular offset. That lets lane width and markings be described as functions of s independent of absolute world position.

Use cases

ADAS testing at BMW and Mercedes-Benz. An OEM engineer takes an OpenDRIVE map of a real stretch of A8 autobahn near Stuttgart, imports it into VTD (Hexagon Simulation), loads an OpenSCENARIO with a cut-in maneuver from an adjacent vehicle, and verifies the ACC algorithm's response. Thousands of such scenarios run nightly on a cluster before every ECU release.

AV development in CARLA Simulator. Open-source simulator from Computer Vision Center (Barcelona), widely used by academic AV researchers. CARLA takes OpenDRIVE as its primary map format — built-in maps Town01-Town12 ship as .xodr, and users can load custom maps via client.load_world_from_opendrive().

Digital twins in city planning. A city department models an intersection rebuild before physical construction — exports the current OSM state into OpenDRIVE, modifies geometry in RoadRunner (MATLAB), runs SUMO-OpenDRIVE co-simulation for traffic flow analysis. Sees impact of new geometry on capacity with no physical construction cost.

NVIDIA DriveSim for AV training data. NVIDIA DRIVE platform uses OpenDRIVE for test route description and synthetic data generation. Real-city maps (Mountain View, San Jose) are imported into DriveSim, photo-realistic sensor data is generated on them for neural-network training.

Academic research on esmini. A PhD student at KIT (Karlsruhe Institute of Technology) researches lane-change algorithms — exports an OSM fragment of the Berlin ring road via osm2cdr into .xodr, opens it in Eclipse esmini viewer for visual lane-geometry validation, then hooks a Python planner into the esmini RoadManager API.

OpenDRIVE vs SUMO vs Lanelet2 vs raw GeoJSON

The transport simulation ecosystem has four main approaches to describing road networks:

• OpenDRIVE — high lane-level geometric precision with mathematically continuous curvature (clothoid spirals), focus on vehicle physics simulation. Primary use: AV/ADAS sim in CARLA, VTD, IPG CarMaker. ASAM standard under industry consortium.
• SUMO — traffic flow simulation, edge-based network with simplified geometry. Primary use: microscopic traffic simulation, mobility modeling. Open-source DLR.
• Lanelet2 — HD map for AV planning, focus on lane semantics and regulatory elements (right-of-way, traffic light inheritance). Primary use: Autoware (open-source AV stack). C++ library + OSM XML schema.
• GeoJSON — general vector format without lane semantics. Not suitable for AV simulation — no topology, no lane attributes, no signal mapping.

OpenDRIVE and Lanelet2 often compete — the first is stronger in geometry and physical accuracy, the second is simpler for planning algorithms. SUMO and OpenDRIVE are complementary — SUMO has conversion tooling netconvert --opendrive-files for loading OpenDRIVE as a traffic network. Many modern simulation stacks use all three: OpenDRIVE for ego vehicle physics, SUMO for surrounding traffic, Lanelet2 for planning.

Strengths and weaknesses

Strengths. Open ASAM standard with industry consortium of 350+ companies — no vendor lock-in. Lane-level geometric precision through clothoid spirals — accurate physics. Native support in every major AV simulator (CARLA, VTD, IPG CarMaker, dSPACE, RoadRunner, esmini). Companion standards (OpenSCENARIO, OpenCRG) form a complete simulation ecosystem. Active development — version 1.9.0 in 2026. Open reference implementation Eclipse esmini.

Weaknesses. OSM doesn't contain lane-level markings — export is always an approximation through heuristics (lane count from lanes=* tag, width from width=* or defaults by highway=* value). Complex XML with math-heavy geometry — debugging requires understanding clothoid curve parameters. File size grows fast for large areas — exporting all of Moscow is impractical. Junction topology in OSM is ambiguous — sloppy maps in some areas, hyper-detailed in others. Lane markings, signal types — must be filled by country-specific catalogs (German vs US sign IDs).

Workflow in OSM2CDR

Our opendrive_exporter.py is a heuristic OSM → ASAM OpenDRIVE 1.7+ converter:

Step 1: Bbox selection (max 1 km²). The user picks a small area on the map — the OpenDRIVE pipeline is computationally heavy, and CARLA / esmini typically need exactly such patches (a city block, an intersection, a highway stretch).

Step 2: PostGIS extraction. From the local PostGIS database we read highway=* ways with tags lanes, width, oneway, maxspeed, name. Plus traffic_signals=* nodes for signal placement and barrier=* ways for objects.

Step 3: Geometry conversion to <planView>. OSM linestrings convert into OpenDRIVE planView geometry. Straight OSM segments → <line> primitives. Curved sections approximated through series of <arc> (constant curvature) or <spiral> (linearly changing curvature) for smoother transitions. The reference implementation uses pyproj for projection into local Cartesian + numpy for curve fitting.

Step 4: Lanes upgrade heuristics. OSM highway=* tag converts to lane count by rules: - highway=motorway without lanes=* → 2 lanes per direction, width 3.75m - highway=primary → 2 lanes per direction, width 3.5m - highway=secondary → 1 lane per direction, width 3.25m - highway=residential → 1 lane per direction, width 3.0m - If a lanes=* tag exists — it's used. Same for width=*. - Sidewalks (sidewalk=both) added as boundary lanes of type sidewalk.

Step 5: Junction topology. Intersections (OSM nodes of degree >= 3) generate as <junction> with auto-generated <connection> entries for all pairs of legal directions. oneway=yes excludes counter-flow.

Step 6: Signal placement. OSM traffic_signals=* nodes are placed as <signal> elements on nearest road segments with German catalog type ID 1000001 (basic traffic light).

Step 7: ASAM XML serialization. Output is a well-formed .xodr with XML schema validation. Validated via esmini import as a regression test in our CI.

A typical export size — 1 km² of Brestskaya street in Moscow → ~250 KB .xodr file with 47 roads, 12 junctions, 23 signals. Loads in esmini in 2 seconds.

FAQ

Which OpenDRIVE version does osm2cdr generate? ASAM OpenDRIVE 1.7 (with <header revMajor="1" revMinor="7"/>). This is the version with the best backward compatibility — opens in every major simulator (CARLA 0.9.13+, VTD 2024, esmini 2.x, IPG CarMaker 12+). If you need 1.8+ — open an issue on our GitHub.

Can I use our export directly in CARLA? Technically yes — client.load_world_from_opendrive() will accept the file. But: OSM-derived maps lack lane-level markings and signal validity that CARLA actors expect. For production AV testing we recommend refining the export in RoadRunner (MATLAB) or manual editing in esmini OdrViewer before use.

What's the difference from SUMO? SUMO is a traffic flow simulator — its network format simplifies down to edges + nodes with primitive geometry. OpenDRIVE is a format for vehicle physics simulation with continuous curvature and lane-level precision. SUMO is faster for city-scale traffic modeling (thousands of machines on cheap hardware). OpenDRIVE is more accurate for individual vehicle dynamics testing.

And Lanelet2? Lanelet2 focuses on lane semantics + regulatory rules (right-of-way, traffic light groupings) for planning algorithms — it's an HD map for autonomy. OpenDRIVE focuses on geometric accuracy for physics simulation. Autoware uses Lanelet2; CARLA uses OpenDRIVE. For academic research the choice depends on what matters more: geometric fidelity (OpenDRIVE) or planning rules (Lanelet2).

Does it support OpenSCENARIO? Yes — companion standard. OpenSCENARIO .xosc files reference OpenDRIVE .xodr via <RoadNetwork><LogicFile filepath="map.xodr"/>. Dynamic scenarios (trajectories, events, maneuvers) are described in .xosc, static infrastructure in .xodr. Eclipse esmini natively supports both.

Conclusion

OpenDRIVE isn't just a file format but the foundation of the entire AV simulation ecosystem with industry-wide adoption at Tier 1 OEMs and AV stack vendors. An open ASAM standard, a clear XML structure with math-heavy geometry, native integration in CARLA / VTD / IPG CarMaker / NVIDIA DriveSim — all of this makes OpenDRIVE the first-choice for describing road networks in any serious AV testing workflow.

OSM2CDR doesn't claim to compete with RoadRunner or ASAM map authoring tools for production-grade AV maps — our export is a quick-start for academic research, prototype scenarios, and educational use cases. If you need a .xodr file of a real Moscow or Berlin district for a CARLA experiment — pick a bbox up to 1 km² and the OpenDRIVE format on the format page, download .xodr, open in Eclipse esmini for verification and continue discovery in your simulator.

Related

• SUMO — traffic flow simulation format from DLR
• Lanelet2 — HD map for Autoware and AV planning
• GeoJSON — open standard RFC 7946
• KML — Google Earth XML for geodata
• Comparison: OpenDRIVE vs SUMO vs Lanelet2

Sources

• ASAM OpenDRIVE — asam.net/standards/detail/opendrive/
• ASAM OpenDRIVE 1.9.0 Specification — publications.pages.asam.net/standards/ASAM_OpenDRIVE
• Eclipse esmini — github.com/esmini/esmini
• CARLA Simulator OpenDRIVE — carla.readthedocs.io/en/latest/core_map
• ASAM OpenSCENARIO — asam.net/standards/detail/openscenario/
• OpenDRIVE Wikipedia — en.wikipedia.org/wiki/OpenDRIVE_(specification)