How to Parse OpenDRIVE XML with Python

In autonomous vehicle localization, simulation, and HD mapping stacks, OpenDRIVE serves as the foundational exchange format for high-definition road networks. Unlike lightweight telemetry payloads, OpenDRIVE encodes dense geometric primitives, multi-layered lane topology, and complex junction connectivity within a deeply nested XML hierarchy. Parsing these files in production requires a strategy that respects strict memory ceilings and deterministic execution bounds. Naive tree-based deserialization routinely exhausts heap allocations when ingesting multi-kilometer corridor tiles, triggering garbage collection thrashing that destabilizes downstream spatial indexing and path-planning modules. This guide details a production-grade parsing workflow engineered for Python-based HD mapping pipelines, emphasizing stream processing, schema enforcement, and robust geometric extraction.

Constant-memory streaming parse: process each road, then release it before the next:

flowchart TD
  A[".xodr file (&gt;50 MB)"] --> B["lxml.iterparse<br/>events=end · tag=road"]
  B --> C["Extract attributes<br/>id · length · lanes"]
  C --> D["elem.clear() +<br/>purge previous siblings"]
  D --> E{"More road<br/>elements?"}
  E -->|"yes"| B
  E -->|"no"| F["XSD validation<br/>(isolated worker)"]
  F --> G["Geometry evaluation<br/>line · arc · spiral · poly3"]
  G --> H["Lane topology + junction<br/>adjacency matrix"]
  H --> I(["Spatial index handoff"])
  classDef io fill:#eef3fa,stroke:#3a56d4,color:#1a2336;
  classDef gate fill:#fff4e5,stroke:#f59e0b,color:#7a4a00;
  classDef out fill:#e7f7f0,stroke:#0c8f6a,color:#0a4b39;
  class A io
  class E gate
  class I out

Streaming Architecture & Memory Management #

The standard xml.etree.ElementTree implementation loads the entire document into memory, which becomes untenable for OpenDRIVE files exceeding 50 MB. For production environments, lxml.etree combined with iterative parsing (iterparse) establishes the baseline for scalable ingestion. By processing the XML stream element-by-element and explicitly releasing processed nodes, the parser maintains a constant memory footprint independent of tile complexity. The following pattern demonstrates a memory-safe extraction loop:

from lxml import etree
from typing import Iterator, Dict, Any

def stream_opendrive_roads(filepath: str) -> Iterator[Dict[str, Any]]:
    context = etree.iterparse(filepath, events=("end",), tag="road")
    for _, elem in context:
        road_data = {
            "id": elem.get("id"),
            "length": float(elem.get("length", 0.0)),
            "junction": elem.get("junction", "-1"),
            "lanes": []
        }
        # Process lane sections, geometry, and elevation profiles here
        # ...
        yield road_data
        elem.clear()
        # Purge preceding siblings to prevent tree retention
        while elem.getprevious() is not None:
            del elem.getparent()[0]

This approach prevents unbounded RAM growth, which is critical when HD Mapping Architecture & Spatial Data Standards dictate sub-500 MB working sets per ingestion worker. Note that iterparse requires explicit namespace handling. While the core specification typically omits XML namespaces, OEM-specific extensions frequently inject unprefixed tags that break XPath resolution. Implementing a lightweight namespace-stripping pass during the initial stream ensures deterministic query behavior across heterogeneous vendor datasets. For reference, the official lxml parsing documentation outlines additional event hooks that can be leveraged for attribute-level filtering before element closure.

Schema Validation & Version Drift #

OpenDRIVE has undergone significant structural revisions between versions 1.4 and 1.6, introducing breaking changes in lane offset interpolation, junction priority rules, and elevation profile sampling. Implicit parsing without strict schema validation risks silent topology corruption that propagates into localization failures. Production pipelines must enforce validation against the official ASAM XSD before topology extraction begins. Using lxml's XMLSchema class, validation can be executed as follows:

from lxml import etree

def validate_opendrive(filepath: str, xsd_path: str) -> bool:
    schema_doc = etree.parse(xsd_path)
    schema = etree.XMLSchema(schema_doc)
    try:
        doc = etree.parse(filepath)
        schema.assertValid(doc)
        return True
    except etree.DocumentInvalid as e:
        # Log error_log for targeted quarantine
        print(schema.error_log)
        return False

Validation should run in an isolated worker thread or subprocess to avoid blocking the main ingestion pipeline. When validation fails, the error log provides precise line/column references for quarantining malformed tiles. Implementing a fallback routing strategy that defaults to simplified reference-line interpolation preserves pipeline continuity while flagging problematic assets for manual review. This gating mechanism aligns with established practices in OpenDRIVE Schema Breakdown, where deterministic validation prevents cascading coordinate transformation errors. The official ASAM OpenDRIVE specification provides version-specific XSD files that should be pinned to your pipeline's release cycle.

Geometric Primitive Extraction & Coordinate Transformation #

Once validated, the parser must reconstruct continuous road geometry from discrete <geometry> primitives. OpenDRIVE defines reference lines using parametric curves (lines, arcs, spirals, polynomials) anchored to a local coordinate system. Each primitive requires precise mathematical evaluation to generate dense waypoint sequences compatible with downstream planners. For example, spiral (clothoid) segments demand Fresnel integral approximations, while cubic polynomial elevations require numerical integration for accurate z-axis sampling.

import numpy as np

def evaluate_geometry(s: float, geom_type: str, params: Dict[str, float]) -> np.ndarray:
    if geom_type == "line":
        return np.array([s, 0.0, 0.0])
    elif geom_type == "arc":
        curvature = params["curvature"]
        return np.array([
            np.sin(curvature * s) / curvature,
            (1 - np.cos(curvature * s)) / curvature,
            0.0
        ])
    # Implement spiral, poly3, paramPoly3 handlers here
    raise NotImplementedError(f"Unsupported geometry type: {geom_type}")

Coordinate transforms must account for the OpenDRIVE right-handed coordinate system (x forward, y left, z up) and apply heading offsets from the parent <road> element. Failing to normalize heading accumulation across geometry segments introduces cumulative drift that degrades localization accuracy. Always cache intermediate transform matrices and apply them lazily during lane boundary generation.

Lane Topology & Junction Connectivity #

Lane parsing requires traversing nested <laneSection> and <lane> elements while tracking dynamic attributes like laneOffset, width, and roadMark. The hierarchical nature of OpenDRIVE means lane IDs reset at each section, necessitating a global mapping layer that resolves laneID to a continuous topological graph. Junction connectivity relies on <connection> and <predecessor>/<successor> tags, which define allowable maneuvers and priority rules. When constructing the adjacency matrix, explicitly handle elementType="road" versus elementType="junction" transitions to prevent invalid routing edges.

Pipeline Integration & Profiling #

In production, OpenDRIVE ingestion should be decoupled from spatial indexing via message queues or shared memory buffers. Profile memory allocations using tracemalloc to verify that elem.clear() effectively releases C-level buffers. For multi-core environments, partition large .xodr files by road segments and distribute parsing across a concurrent.futures.ProcessPoolExecutor. This architecture ensures deterministic latency, prevents GIL contention, and maintains compatibility with high-throughput mapping pipelines.

Conclusion #

Parsing OpenDRIVE XML in autonomous vehicle stacks demands a rigorous, memory-conscious approach that prioritizes streaming deserialization, strict schema validation, and mathematically precise geometric reconstruction. By leveraging lxml's iterative parsing capabilities, enforcing ASAM-compliant validation gates, and implementing robust coordinate transformation pipelines, engineering teams can reliably ingest multi-kilometer road networks without compromising localization stability or spatial indexing performance.