Geometric Deep Learning for Autonomous Driving: Unlocking the Power of
  Graph Neural Networks With CommonRoad-Geometric
Heterogeneous graphs offer powerful data representations for traffic, given
their ability to model the complex interaction effects among a varying number
of traffic participants and the underlying road infrastructure. With the recent
advent of graph neural networks (GNNs) as the accompanying deep learning
framework, the graph structure can be efficiently leveraged for various machine
learning applications such as trajectory prediction. As a first of its kind,
our proposed Python framework offers an easy-to-use and fully customizable data
processing pipeline to extract standardized graph datasets from traffic
scenarios. Providing a platform for GNN-based autonomous driving research, it
improves comparability between approaches and allows researchers to focus on
model implementation instead of dataset curation.
Eivind Meyer, Maurice Brenner, Bowen Zhang, Max Schickert, Bilal Musani, Matthias Althoff
Geometric Deep Learning for Autonomous Driving: Unlocking the Power of Graph Neural Networks With CommonRoad-Geometric

###### Abstract

Heterogeneous graphs offer powerful data representations for traffic, given their ability to model the complex interaction effects among a varying number of traffic participants and the underlying road infrastructure. With the recent advent of graph neural networks (GNNs) as the accompanying deep learning framework, the graph structure can be efficiently leveraged for various machine learning applications such as trajectory prediction. As a first of its kind, our proposed Python framework offers an easy-to-use and fully customizable data processing pipeline to extract standardized graph datasets from traffic scenarios. Providing a platform for GNN-based autonomous driving research, it improves comparability between approaches and allows researchers to focus on model implementation instead of dataset curation.

## I Introduction

Machine learning agents require an accurate understanding of the surrounding traffic context to make safe and effective decisions [1]. This calls for a descriptive representation not only of the various entities within the traffic environment, but also their complex spatial and temporal relationships. When restricted to a fixed-size feature space--a prerequisite for classical neural networks--this is a particularly challenging prospect given the inherent complexity and variability in road geometries and traffic situations.

An alternative approach is to model the environment state in the form of a heterogeneous graph, encompassing both the road network topology and the traffic participants present in it. This structured representation allows us to capture a wide range of road networks and traffic scenarios with a variable number of discrete elements. Additionally, it enables the explicit modeling of pairwise relationships or interactions between entities through edge connections. Graph neural networks (GNNs) have recently emerged as the principal deep learning framework for processing graph data [2, 3, 4, 5]. By using GNNs, the graph topology can be exploited as a relational inductive bias [5] during training, aiding generalization.

### _Related work_

Graph-structured representations of traffic proposed in existing works differ based on the objectives of the learning task. In [6], the authors let nodes represent individual road segments with edges forming the overarching road network topology for driving speed estimation and road network classification. Alternatively, [7] and [8] present graph-based traffic forecasting approaches in which nodes are used to model traffic participants and edges are used to capture vehicle interactions. Similarly, [9] and [10] adopt vehicle-to-vehicle GNNs as policy networks for reinforcement learning agents. Additionally considering the temporal dimension, [11] employs a spatiotemporal vehicle graph for capturing time-dependent features. Finally, recent works [12, 13, 14, 15, 16, 17, 18, 19, 20] incorporate both vehicle and map nodes by modelling the environment as a heterogeneous graph, including both inter-vehicle as well as vehicle-road interaction effects.

### _Motivation and contributions_

Despite the vast research interest, there is no software framework that offers an interface for extracting custom graph datasets from traffic scenarios. Although there are plenty of autonomous driving datasets, e.g. [21, 22, 23], researchers have to write considerable amounts of ad-hoc, error-prone conversion code to use them as inputs for GNN models. As evident by the success in other application domains such as bioinformatics and social networks [24, 25], standardized graph datasets would enable autonomous driving researchers to streamline their experiments and ensure comparability and repeatability of their results.

To fill this gap, we propose _CommonRoad-Geometric (cr-geo)_: a Python library designed to facilitate the extraction of graph data from recorded or simulated traffic scenarios. Our framework extends the _CommonRoad_[26] software platform and uses its standardized interface for a high-level representation of the traffic environment. As illustrated by Fig. 1, our framework unifies the traffic scene into a single graph entity, encompassing both the traffic participants and the underlying road map. The extracted graph representations are based on the HeteroData class offered by _PyTorch-Geometric_[27], a popular _PyTorch_[28] extension for deep learning on graph-structured data.

Our paper offers the following contributions:

* we introduce a heterogeneous graph structure for map-aware traffic representations tailored to GNN applications;
* we present and outline the software architecture of _CommonRoad-Geometric (cr-geo)_, which offers a bridge from the well-established CommonRoad scenario format to _PyTorch-Geometric (PyG)_;
* as a concrete example of the wide range of GNN-based applications facilitated by _cr-geo_, we train a spatiotemporal trajectory prediction model on a real-world graph dataset extracted from NuPlan [23].
## II Background

We first provide some background on heterogeneous graphs and the description of scenarios in CommonRoad.

#### Ii-1 Heterogeneous graphs

A directed heterogeneous graph \(\mathcal{G=(V,E,A,R,X_{V},X_{E})}\) is defined as a tuple of a set of nodes \(\mathcal{V}\), edges \(\mathcal{E}\), node types \(\mathcal{A}\), edge types \(\mathcal{R}\), and corresponding node and edge features \(\mathcal{X}_{\mathcal{V}}\) and \(\mathcal{X}_{\mathcal{E}}\)[29]. Edges are defined as a 3-tuple \(\mathcal{E\subset V\times R\times V}\). Further, each node \(v\in\mathcal{V}\) is assigned a node type via the mapping \(\tau_{V}(v):\mathcal{V\rightarrow A}\). Analogously, edges \(e\in\mathcal{E}\) are associated with an edge type \(\tau_{\mathcal{E}}(e):\mathcal{E\rightarrow R}\). Finally, \(\mathcal{X}_{\mathcal{V}}\) and \(\mathcal{X}_{\mathcal{E}}\) contain the feature vectors, which we denote as \(\mathbf{x}_{v}\in\mathbb{R}^{D_{\mathcal{V}}}\) for node features and \(\mathbf{x}_{e}\in\mathbb{R}^{D_{\mathcal{E}}}\) for edge features. Fig. 2 illustrates graph features on the node and edge level.

#### Ii-2 CommonRoad

A CommonRoad _scenario_ contains a set \(\mathcal{V}^{cr}\) of _dynamic obstacles_. For a vehicle \(V\in\mathcal{V}^{cr}\) of rectangular shape \((l_{V},w_{V})\), we represent its time-dependent state by its x-y center position \(\mathbf{p}_{V}\), its orientation \(\theta_{V}\), as well as their time derivatives in the scenario coordinate frame.

Further, the map-related information of a scenario is described by its _lanelet network_, containing a set \(\mathcal{L}^{cr}\) of atomic _lanelets_ and their longitudinal and lateral adjacency relations [30]. Lanelets are geometrically defined by their boundary polylines. For a lanelet \(L\in\mathcal{L}^{cr}\), we denote its left and right boundary polylines as \(S_{L,l}\) and \(S_{L,r}\), respectively. Further, we denote the center polyline as \(S_{L,c}\). Each polyline is made up of a sequence of \(N_{L}\) waypoints in the scenario coordinate frame. Using the notation \(\langle\square_{i}\rangle_{i\in 1,\ldots,N}\) to define a sequence of values of length \(N\), we let the polylines be denoted as \(S_{L,l}=\langle\vec{s}_{i,i}\rangle_{i\in 1,\ldots,N_{L}}\), \(S_{L,r}=\langle\vec{s}_{r,i}\rangle_{i\in 1,\ldots,N_{L}}\), and \(S_{L,c}=\langle\vec{s}_{c,i}\rangle_{i\in 1,\ldots,N_{L}}\). With \(\|\|_{2}\) denoting the L2-norm, we further define the lanelet length as

\[\|L\|_{2}=\sum_{i=1}^{N_{L}-1}\sqrt{\|\vec{s}_{c,i+1}-\vec{s}_{c,i}\|_{2}}, \tag{1}\]

## III Overview

In the following subsections, we define the structure of our traffic graph and outline the software architecture of our framework.

### _Traffic graph structure_

Extending _PyG_'s HeteroData1, _cr-geo_'s CommonRoadData class represents a heterogeneous traffic graph encapsulating nodes of both the vehicle (v) and lanelet (l.) node type, as well as the structural metadata for the specific graph instance. Formally, we have that \(\mathcal{A=\{v,L\}}\) and \(\mathcal{R=\{L2,v2v,v2L,12v\}}\).

Footnote 1: [https://pytorch-geometric.readthedocs.io/en/latest/modules/data.html#torch.geometric.data.Heter0data](https://pytorch-geometric.readthedocs.io/en/latest/modules/data.html#torch.geometric.data.Heter0data)

In order to capture temporal vehicle interactions with GNN-based message-passing schemes, we further extend the CommonRoadData class by the time dimension with CommonRoadTemporalData, where \(\mathcal{R}\) is augmented by the temporal vtv edge type. The resulting _temporal graph_[31], as shown in Fig. 3, intrinsically encodes the temporal dimension by unrolling the traffic graph over time. Vehicle nodes are repeated to capture vehicle states at past timesteps, and temporal edges encode the time difference between them.

Fig. 1: Our package serves as a bridge from CommonRoad to PyTorch-Geometric. The abbreviated graph labels refer to the heterogeneous node and edge entities of our unified traffic graph structure covered in Section III-A.

Fig. 2: Illustration of a simple graph structure. Edge types are represented as different colors. Colored squares represent features vectors for nodes (e.g., vehicle speed) and edges (e.g., distance between vehicles).
The heterogeneous structure of our graphical data representation is summarized in Tab. II and outlined in the following paragraphs:

#### Iii-B1 Lanelet nodes \((\mathcal{V}_{L})\)

Lanelet nodes map to the lanelets in \(\mathcal{L}^{cr}\), with each lanelet \(L\) being represented as a graph node. The corresponding node features encode the geometric properties of the respective lanelets. Using the general notation \({}^{L}\square\), we denote the lanelet-local transformed polyline coordinates as \({}^{L}S_{L,l}\), \({}^{L}S_{L,c}\), and \({}^{L}S_{L,r}\). Here, the vertex coordinates are transformed to the lanelet-local coordinate frame according to its origin position \(\mathbf{p}_{L}=\vec{s}_{c,1}\) and its orientation \(\theta_{L}=\mathrm{atan2}\left(\nicefrac{{s_{c,2}}}{{s_{c,1}}}\right)\). In the following, we also let the function interpretations \(\tilde{S}_{L,\square}(\cdot)\) and \(\tilde{\theta}_{L}(\cdot)\) be defined via orthogonal projections onto the polylines, returning the position and orientation at a given arclength, respectively.

#### Iii-B2 Lanelet-to-lanelet edges \((\mathcal{E}_{\mathrm{l2L}})\)

Lanelet-to-lanelet edges characterize the lanelet network topology and encode the spatial relationship between adjacent lanelets. As illustrated by Fig. 4, we explicitly differentiate between the heterogeneous L2L adjacency types \(\mathcal{R}_{\mathrm{l2L}}\) listed in Tab. I via the edge feature \(\tau_{\mathcal{E}}\). For an edge from \(L\) to \(L^{{}^{\prime}}\), we also include their centerline arclength distance at the point of intersection as edge features, which we denote by \(s_{L}\) and \(s_{L^{\prime}}\). This is highlighted in Fig. 4c for two conflicting lanelets.

#### Iii-B3 Vehicle nodes \((\mathcal{V}_{V})\)

Vehicle nodes are inserted according to the states of the currently present vehicles and identified by their CommonRoad IDs. As shown in Fig. 3, CommonRoadTemporalData additionally includes past vehicle states in the graph representation: here, a vehicle's state history is captured by time-attributed (but otherwise identical) vehicles nodes inserted at each timestep.

#### Iii-B4 Vehicle-to-vehicle edges \((\mathcal{E}_{\mathrm{v2v}})\)

Vehicle-to-vehicle edges capture the interaction between vehicles at each timestep. The relative pose of connected vehicles is encoded as edge features according to the vehicle-local coordinate frame originating at the center of the source vehicle. Users can provide a specific implementation of our v2v _edge drawer_ protocol to encode which v2v relations are relevant for their task. Our framework offers developers a set of standard edge drawer implementations, two of which are depicted in Fig. 5.

#### Iii-B5 Vehicle-to-lanelet edges \((\mathcal{E}_{\mathrm{v2L}})\)

Vehicle-to-lanelet edges relate vehicles to the underlying road infrastructure. Our framework offers two assignment strategies for drawing the edges:

1. **Center**: Each vehicle is connected to all lanelets that contain the vehicle center point.
2. **Shape**: Each vehicle is connected to all lanelets that intersect with the vehicle shape. This constitutes a superset of the edges drawn by the _Center_ strategy.

The associated edge features describe the relative pose of the vehicle with respect to the curvilinear lanelet coordinate frame [32]. For a given edge from vehicle \(V\) to lanelet \(L\), we denote the orthogonal distance from the lanelet's left and right boundaries to the vehicle center as

\[\begin{split} d^{L}_{V,l}&=\|\tilde{S}_{L,l}(\mathbf{ p}_{V})-\mathbf{p}_{V}\|_{2},\\ d^{L}_{V,r}&=\|\tilde{S}_{L,r}(\mathbf{p}_{V})- \mathbf{p}_{V}\|_{2}.\end{split} \tag{2}\]

\begin{table}
\begin{tabular}{c c} \hline \hline
**Type** & **Interpretation** \\ \hline predecessor & \(L\) continues the driving corridor of \(L^{\prime}\) \\ successor & \(L^{\prime}\) continues the driving corridor of \(L\) \\ adjacent left & \(L\) is left-adjacent to \(L^{\prime}\) \\ adjacent right & \(L\) is right-adjacent to \(L^{\prime}\) \\ merging & \(L\) and \(L^{\prime}\) share a common successor (symmetric) \\ diverging & \(L\) and \(L^{\prime}\) share a common predecessor (symmetric) \\ conflicting & \(L\) and \(L^{\prime}\) cross each other (symmetric) \\ \hline \hline \end{tabular}
\end{table} TABLE I: L2L adjacency types for edges \(L\to L^{\prime}\). The considered adjacency types can be individually selected at the user’s preference.

Fig. 3: Visualization of Voronoi-based v2v and causal vtv edges for a highway scenario. Opaque colors denote the most recent edges while more transparent shades represent older ones.
Further, we define the signed offset from the centerline as

\[d_{V,e}^{L}=\frac{d_{V,l}^{L}-d_{V,r}^{L}}{2} \tag{3}\]

and let \(s_{V}^{L}\in[0,\|L\|_{2}]\) denote the centerline arclength from the lanelet origin \(\mathbf{p}_{L}\) to \(\tilde{S}_{L,c}(\mathbf{p}_{V})\). Finally, the orientation difference is given by

\[\theta_{V,e}^{L}=\tilde{\theta}_{L}(\mathbf{p}_{V})-\theta_{V}. \tag{4}\]

#### Iii-A6 Vehicle-temporal-vehicle edges \((\mathcal{E}_{\textsc{vtv}})\)

CommonRoadTemporalData additionally contains temporal vehicle edges for encoding temporal dependencies in the traffic graph: Letting \(v_{t}\) and \(v_{t^{{}^{\prime}}}\) denote two vehicle nodes emerging from one vehicle instance, a temporal edge \(e\in\mathcal{E}_{\textsc{vtv}}\) connects the vehicle object to itself at two different timesteps, as illustrated by Fig. 3. The temporal separation between the nodes is defined as the elapsed time \(\Delta t_{e}=t-t^{{}^{\prime}}\).

As for v2v, _cr-geo_ lets users specify a custom _temporal edge drawer_ for defining the exact vtv graph structure. The default CausaEdgeDrawer inserts directed temporal edges between a historic vehicle node and its future realization at up to \(T_{max}^{\textsc{vtv}}\) future time steps. This constrains the flow of the vtv edges to be forward in time.

### _Software architecture_

Next, we outline the principal components of our software architecture in a bottom-up approach, by detailing the pipeline for collecting graph datasets from CommonRoad scenarios. An architecture overview is given by Fig. 6.
#### Iv-A2 Scenario preprocessing and filtering

Our framework supports arbitrary preprocessing and filtering of the input scenarios to ensure that they satisfy the user requirements. As an example, TrafficFilter(min=10) lets users exclude scenarios with less than \(10\) vehicles from the collected graph dataset. Further, suppose that we want a higher-fidelity view of the lanelet network, where no lanelet exceeds \(20\) meters in length: this can be achieved by using _cr-geo_'s built-in SegmentLanelets_preprocessor_, which results in a higher lanelet node density. Using our composition syntax that realizes arbitrary chaining and grouping of preprocessing and filtering operations, these behaviors can be effortlessly combined via

TrafficFilter(min=10) > SegmentLanelets(size=20).

#### Iv-A3 Feature extraction

The extraction of the graph features, i.e., \(\mathcal{X}_{\mathcal{V}}\) and \(\mathcal{X}_{\mathcal{E}}\), is carried out through _feature extractors_ operating on the scenario objects. The feature extractors receive a _simulation_ object, which provides access to inherent and derived state information of the scenario at the current timestep. By maintaining an internal state, feature extractors also support time-dependent features.

In our framework, we distinguish between node- and edge-level feature extractors, with the latter operating on pairs of entities according to \(\mathcal{E}\). In accordance with _cr-geo_'s guiding design principles, users can devise their own implementation to augment the extracted graphs by arbitrary custom features without modifying the _cr-geo_ source code. To reduce the initial setup time for new users, _cr-geo_ also offers users a selection of pre-configured feature extractor implementations designed to meet the most common needs and requirements.

#### Iv-A4 Postprocessors

In contrast to the aforementioned node- and edge-level feature extractors, _postprocessors_ operate directly on the graph instances in a deferred manner. As such, they are intended to supplement the flexibility we concede in the otherwise rigorous graph extraction procedure. User-devised postprocessing procedures can serve numerous practical purposes, e.g.,

* to complement the functionality of feature extractors by facilitating the computation of graph-global features, e.g., an indicator for whether the current traffic scene corresponds to a traffic jam or not;
* to modify the graph structure, e.g., by the removal or insertion of nodes and edges.

The postprocessors are executed after the initial graph extraction, but prior to dataset generation. Furthermore, they can also be applied while loading an existing dataset.

#### Iv-A5 Traffic graph extraction

The execution of edge drawing, feature extraction and postprocessing is orchestrated by a _traffic extractor_, which manages the creation of a CommonRoadData instance at a single timestep \(t\). It also handles the declaration of metadata attributes such as node IDs.

The traffic extractor class is complemented by the _temporal traffic extractor_ for the purpose of extracting temporal graph representations. Internally relying on a regular traffic extractor, it maintains a cache of the \(n\) preceding ordinary CommonRoadData instances at all times. When called upon, it returns the CommonRoadTemporalData at the current timestep by merging the cached graph sequence into a single entity. The temporal extractor delegates the temporal edge construction to the provided _temporal edge drawer_ and the computation of custom temporal features to the vtv feature extractors provided by the user. The regular and temporal extraction procedures are summarized by Alg. 1 and Alg. 2, respectively.

#### Iv-A6 Dataset creation

Based on the provided traffic graph extractor, the _dataset collector_ offers an interface for generating a chronological sequence of graph instances from a specified scenario. The collector iterates over consecutive timesteps until it reaches the end of the scenario lifetime, dynamically returning the extracted graph objects. Whereas the static simulation mode corresponds to a replay of the recorded vehicle trajectories contained within the CommonRoad scenario, the interactive mode leverages an interactive traffic simulator for on-the-fly generation of realistic vehicle behavior. One such implementation is provided by the traffic simulation tool SUMO [36], which we access via our CommonRoad interface [37].

Finally, the creation and accessing of a persistent graph dataset collected from a set of input scenarios is facilitated by the CommonRoadDataset, a full-fledged extension of the powerful Dataset2 class natively offered by _PyG_. As such,

Fig. 6: High-level software architecture for _cr-geo_ shown as a UML 2 component diagram [33].
our dataset class allows users to easily perform common data operations such as batching, sampling, and parallelization on the collected dataset during model training. As the individual graph instances inherit from the base data representation used by _PyG_, _cr-geo_ practitioners can effortlessly adopt their wide selection3 of state-of-the-art GNN architectures. The dataset creation procedure is summarized by Alg. 3.

Footnote 3: [https://pytorch-geometric.readthedocs.io/en/latest/modules/](https://pytorch-geometric.readthedocs.io/en/latest/modules/)

```
Configuration:
``` 

```
Configuration:
``` 

```
Configuration:
``` Configuration: 

```
``` Configuration:
``` Configuration: 

```
```
``` 

```
```
``` 

```
```
``` Configuration: 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

```
```
``` 

\end{tabular}

```
```
``` 

```
```
``` 

```
\end{tabular}
``` 

```
```
``` 

\end{tabular}

```
\end{tableular}
``` 

\end{table}

```
``` 

\end{table}
``` 

\end{table}

``` 
\begin{tabular}{}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\begin{tabular}{}

\end{tabular}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\end{table}

\begin{tabular}{}

\end{table}

\end{table}

\end{table}

\end{table}

\end{table}

\end{table}

\end{table}

\end{table}
## IV Dataset and Experiment

To demonstrate the usage of our framework, we published4 a graph-converted dataset with a diverse set of real-world road geometries. With the help of the dataset converter5, we use the NuPlan [23] dataset as our data source, due to the diversity in the incorporated locations and environments. The extracted graph dataset contains _cr-geo_'s default graph features as previously listed in Tab. II.

Footnote 4: [https://commonroad.in.tum.de/datasets](https://commonroad.in.tum.de/datasets)

Footnote 5: [https://commonroad.in.tum.de/tools/dataset-converters](https://commonroad.in.tum.de/tools/dataset-converters)

### _Experiment_

As an example use case of our framework, we briefly6 introduce a spatiotemporal GNN model for vehicle trajectory prediction based on our CommonRoadTemporalData environment representation. We implement an end-to-end trainable encoder-decoder architecture based on the message passing framework offered by _PyG_:

Footnote 6: The model implementation can be found in the _cr-geo_ repository.

#### Iv-A1 Encoder component

The GNN encoder, for which we use an adapted version of the Heterogeneous Graph Transformer (HGT) architecture proposed in [38], computes a node-level embedding for each vehicle via message passing-based aggregation. This fixed-sized vector encoding summarizes the social and map-related information required to predict its future movement in the current traffic environment. In order to exploit all properties of the graph-structured data, we implement an edge-enhanced HGT architecture that computes attention weights and messages based on both node and edge features. To accelerate learning, we further carry out three (trainable) encoding steps that are applied before the graph convolution layers:

* For encoding the delta-time attribute \(\Delta t_{e}\) of the vtv edges, we adopt Time2Vec [39], a learnable vector representation of time that lets us capture periodic and non-periodic time series patterns.
* To get fixed-sized node representations for the lanelet geometries, we use a Gated Recurrent Unit (GRU) [40] which encodes the variable-length waypoint sequences \({}^{L}V_{l}\) and \({}^{L}V_{r}\).
* Finally, we adopt a learnable vector embedding to encode the l2l adjacency type \(\tau_{\mathcal{E}}\).

#### Iv-A2 Decoder component

Based on the encoded vehicle representations, a GRU decoder network generates a fixed-length sequence of local position and orientation deltas for each vehicle, which is aggregated to obtain a sequence of predicted vehicles states. This is done by repeatedly updating the decoded vehicle state by a local transition in the coordinate frame of the previous state. The model is trained to minimize the average displacement error (ADE) between the predicted and ground-truth vehicle trajectories. An example of the resulting predictions with a prediction horizon of \(1.0~{}\mathrm{s}\) and a time interval of \(0.2~{}\mathrm{s}\) is shown in Fig. 8, whereas the quantitative results are summarized in Tab. IV.

## V Conclusion

This paper presents _cr-geo_, an open-source Python package offering a standardized interface for map-aware graph extraction from traffic scenarios. As a pioneering effort, it serves as a flexible framework that lets users collect custom graphical PyTorch datasets tailored to their research needs. Exemplified by our trajectory prediction implementation, it minimizes the time spent by researchers on writing boilerplate code for dataset collection. _cr-geo_ complements the CommonRoad software platform, which offers a converter tool for popular traffic datasets. With ease of use and extension being our core design goals, _cr-geo_'s flexible interface is achieved by delegating and encapsulating all steps of the traffic graph creation. We invite researchers to contribute to _cr-geo_ to further enhance its capabilities.

## Acknowledgements

This research was funded by the German Research Foundation grant AL 1185/7-1 and the Federal Ministry for Digital and Transport through the project KoSi.
