A Concise Survey on Lane Topology Reasoning for HD Mapping

In plain words

Self-driving cars and map builders need more than the position of each lane. They also need to know how lanes connect: which lane continues into which one at a junction, and which traffic light governs which lane. This survey collects the methods that try to work this out. It sorts them by where their input comes from: old rule-based road-network generators, methods that read roads from aerial pictures, and methods that use cameras and other sensors on the car itself. The paper calls the last group the current state of the art.

The survey also explains how these methods are scored. Some scores check the road network as a whole, and others check whether each lane is matched and whether the links between lanes are right. It then lists the reported scores on two benchmarks and names open problems: too little training data, models too heavy for a car's computer, and little work on cameras placed at the roadside.

TL;DR

• Survey of lane topology reasoning for HD maps, from procedural modeling to learned onboard-sensor systems §1, §2.
• Three paradigms: procedural modeling, aerial imagery and onboard sensors. The paper calls the onboard group the current state of the art §1, §2.3.
• Road-level metrics are APLS and TLTS; lane-level metrics are DET_l and TOP_ll §3.2, eq. 4–7.
• Scores are tabulated on Topo-Boundary (aerial, tab. 2) and OpenLane-V2 (onboard, tab. 3). The paper does not say whether they were re-run or copied.
• No new method and no official code. What an implementer can use here is the metric definitions and the generic onboard pipeline §2.3, §3.2.

Problem

Lane topology reasoning asks how lanes connect and relate, not only where they are. Connections matter for safe navigation §1, fig. 3.

• Procedural modeling produces virtual road networks from hand-designed rules. It has limited controllability, and finding how a rule changes the output takes much trial and error §2.2.
• Aerial imagery methods are hurt by occlusion from buildings and trees, and they recover only coarse, road-level networks. The paper says they are unsuitable for automatic HD map construction or for vehicle planning §2.3.
• Onboard methods have large models. This limits deployment on vehicles and edge devices with tight compute and energy budgets §4.
• No consistent evaluation metric exists for procedural methods, so the survey does not compare them §3.2.

The paper states no assumptions about its own scope beyond the three paradigms and the benchmarks it lists §1, §3.

Method

The paper has no method of its own. It describes three families and one generic onboard pipeline §2.3, fig. 6.

1. Procedural modeling §2.1. Virtual urban maps are built from 2D city maps. Techniques include templates, L-systems, tensor fields, terrain-aware constraints, traffic simulation, sketches and examples. Users tune parameters interactively §2.1.
2. Aerial imagery §2.2. Two routes. (a) Segment road pixels with a segmentation network, then apply morphological post-processing to extract topology. (b) Build a graph: either iteratively, by starting from seed vertices and adding vertices and edges through predefined decision functions, or directly, by encoding the image, predicting vertices, then decoding an adjacency matrix §2.2.
3. Onboard sensors §2.3. Camera images, optionally with LiDAR, SD maps or traffic elements, go through a backbone (ResNet or Swin Transformer), a perspective transform to bird's-eye view, a lane centerline decoder, and a topology decoder §2.3, fig. 6.
4. Centerline decoder. A transformer decoder with a set of learned query vectors, each one mapping a centerline instance §2.3.
5. Topology decoder. Predicts links between centerline instances with GNNs, MLPs or language models. The paper lists these sub-routes: MLP heads over pairs, minimal-ring coverage for intersections, path-to-graph recovery, autoregressive graph generation, graph models over detected centerline vertices, and serialised centerlines fed to language models §2.3.

The pipeline below paraphrases steps 3 to 5. The survey gives no shapes and no pseudocode, so only the step order is taken from the paper.

# Generic onboard-sensor pipeline  [§2.3] [fig. 6]
# Input:  camera images, optionally LiDAR points or an SD map
# Output: lane centerlines and a lane-to-lane topology matrix
def lane_topology(images):
    # Image features from a backbone such as ResNet or Swin  [§2.3]
    features = backbone(images)
    # Map image features into a bird's-eye-view representation  [§2.3]
    bev = perspective_transform(features)
    # Learned query vectors each decode one centerline instance  [§2.3]
    centerlines = centerline_decoder(bev, learned_queries)
    # Predict links between centerline instances  [§2.3]
    topology = topology_decoder(centerlines)
    return centerlines, topology

Metric definitions

Road-level metrics for aerial methods are precision, recall and F1 with a relax ratio τ §3.2, eq. 1–3, plus APLS and TLTS §3.2, eq. 4–5. Lane-level metrics for onboard methods are DET_l and TOP_ll §3.2, eq. 6–7.

Precision = \frac{\left | \left \{ p \mid d(p,Q) < \tau,\ \forall p \in P \right \} \right |}{\left | P \right |} eq. 1

Recall = \frac{\left | \left \{ q \mid d(q,P) < \tau,\ \forall q \in Q \right \} \right |}{\left | Q \right |} eq. 2

F1 = \frac{2 \times Precision \times Recall}{Precision + Recall} eq. 3

APLS = 1 - \min\left(1, \frac{\left | l(g_1,g_2) - l(p_1,p_2) \right |}{l(g_1,g_2)}\right) eq. 4

\left | l(g_1,g_2) - l(p_1,p_2) \right | > l(g_1,g_2) \cdot \phi eq. 5

DET_l = \frac{1}{\left | T \right |} \sum_{t \in T} AP_t, \quad T = \{1.0, 2.0, 3.0\} eq. 6

TOP_{ll} = \frac{1}{\left | V \right |} \sum_{v \in V} \frac{\sum_{\hat{n}' \in \hat{N}'(v)} P(\hat{n}')\, \mathbb{1}(\hat{n}' \in N(v))}{\left | N(v) \right |} eq. 7

The symbols are defined in the text after each equation §3.2: P and Q are predicted foreground pixels and the ground-truth road-boundary graph; d is the shortest Euclidean distance; g1, g2 and p1, p2 are vertex pairs in the ground-truth and predicted graphs; φ is the TLTS tolerance; N(v) is the confidence-ordered neighbour list of vertex v; AP_t is the average precision at Fréchet threshold t §3.2.

The APLS and TLTS procedure below follows the text of §3.2. The sampling scheme is not stated in the paper, so the pair list is an input.

# APLS and TLTS over sampled vertex pairs  [§3.2] [eq. 4] [eq. 5]
# Input:  ground-truth graph, predicted graph, list of vertex pairs
# Output: mean APLS and TLTS over the pairs
def road_scores(gt_graph, pred_graph, pairs, phi):
    # Shortest-path lengths in each graph for every pair  [§3.2]
    apls_values = []
    passing = 0
    for g1, g2, p1, p2 in pairs:
        gt_len = shortest_path(gt_graph, g1, g2)
        pred_len = shortest_path(pred_graph, p1, p2)
        # Relative length error, capped at 1  [eq. 4]
        error = min(1, abs(gt_len - pred_len) / gt_len)
        apls_values.append(1 - error)
        # Pair fails when it is too long or too short  [eq. 5]
        if abs(gt_len - pred_len) <= gt_len * phi:
            passing += 1
    apls = mean(apls_values)
    # TLTS is the share of pairs that are not too long or too short  [§3.2]
    tlts = passing / len(pairs)
    return apls, tlts

Hyperparameters

Results

Author-reported, as compiled by the survey. The survey does not run the methods itself, and the text does not say, row by row, whether a number was re-run or copied from its source paper.

• Aerial, Topo-Boundary: 2D dataset, 25k RGB images at 1000 × 1000, USA, 2021 tab. 1. Scores in tab. 2.
• Onboard, OpenLane-V2: 3D dataset, 466k images at 1600 × 900, 2048 × 1550 or 1550 × 2048, worldwide, 2024 tab. 1. Subset A is derived from Argoverse 2 and subset B from nuScenes §3.1. Scores in tab. 3.

Aerial results on Topo-Boundary tab. 2:

Onboard results on OpenLane-V2 tab. 3, with ResNet-50 and 24 epochs per the caption:

A dash appears in the source table; the paper gives no meaning for it.

The paper's headline claim is qualitative: onboard methods are the state of the art, and recent methods handle complex topology better §5. It names no cross-dataset number to support this.

Paper vs code

No official code. The LaTeX source [raw/src/2504.01989/root.tex] contains no repository link, project page or code comment. The paper is a survey and implements nothing of its own.

Pitfalls

• Eq. 1 and 2 are ambiguous. The ∀ sits inside the set. The text calls Q a ground-truth road-boundary graph, yet Eq. 2 treats its elements as points. Pixel rasterisation and point sampling are not described. The unit of τ (pixels or metres) is not stated §3.2.
• TLTS is never written as a formula. The paper defines it by negation: the share of pairs for which Eq. 5 does not hold §3.2. Whether an unreachable predicted pair counts as failing is not stated.
• APLS and TLTS sampling is not described. The paper says vertices are chosen at random and averaged over all selected pairs. The number of pairs, the seed, and handling of disconnected pairs are not stated §3.2.
• AP_t in DET_l is not defined here. The match rule, the score ordering, and the unit of the Fréchet thresholds are not given. The paper cites OpenLane-V2 for the metric §3.2, eq. 6.
• TOP_ll notation is inconsistent. The text writes P(v), the formula writes P(n̂′). N̂′(v) is not defined. "Precision of the i-th vertex in N(v)" does not say which match decides a true positive or how ties in confidence are broken §3.2, eq. 7. Implement from the OpenLane-V2 definition, not from this survey alone.
• Tables 2 and 3 cannot be ranked against each other. They use different datasets and different metrics tab. 2, tab. 3.
• Table 3 has gaps. SMERF, LaneSegNet and Topo2D have no subset B numbers, so they cannot be compared with the other rows on that subset tab. 3.
• Setup claims are not per row. The caption of tab. 3 says ResNet-50 and 24 epochs apply to all methods, but the survey gives no per-row source. Table 2 has no setup note at all tab. 2.
• Timeline claims have no counts. Procedural methods before 2017, aerial from 2017 to 2022, onboard since 2023 come from the timeline figure §2, fig. 2. The survey gives no counts behind the figure.
• Roadside fusion is called underexplored without a citation §4.
• No figures are used on this card. The paper's Fig. 1 is "adapted from OpenLane-V2" fig. 1, so it is not reproduced here. Figures are described in words only.

Lineage

• Builds on: surveys the authors cite for HD map creation and lane topology construction, keyed bao2023review, chen2022milestones and elghazaly2023high §1. None of them has a card here.
• Compared against: the methods in tab. 2 and tab. 3. Cards exist for TopoMLP and TopoLogic, both in tab. 3.
• Superseded by: not stated.