Meta-GeoLane: Adaptive Lane Detection

• Meta-GeoLane is a meta-learning layer that adaptively generates scene-specific hyperparameters for the GeoLane lane detection pipeline using features like trajectory statistics and time-of-day.
• It optimizes settings for histogram smoothing, clustering, and spline fitting, thereby enhancing lane geometry detection across diverse and complex roadway scenes.
• Its federated extension, FedMeta-GeoLane, enables secure cross-site parameter sharing with over 98% communication reduction while significantly improving detection performance on both seen and unseen locations.

Meta-GeoLane is a scene-adaptive, black-box meta-learning layer built on top of the GeoLane knowledge-based lane detection pipeline within Geo-ORBIT, a federated digital twin framework for dynamic roadway geometry sensing. Its function is not to replace the underlying detector, but to generate per-location detection parameters for GeoLane from scene-level features such as trajectory statistics and time-of-day, thereby personalizing lane geometry inference across heterogeneous roadside camera deployments. In Geo-ORBIT, this role is further extended by FedMeta-GeoLane, which trains the same meta-learner in a federated manner so that roadside sites share meta-parameters rather than raw video or trajectory data (Tamaru et al., 11 Jul 2025).

1. System placement within Geo-ORBIT

Meta-GeoLane is defined inside a larger sensing-and-synchronization loop. On the physical side, Geo-ORBIT uses multiple roadside sensing units, implemented in the reported experiments with WisDOT cameras, to detect vehicles and reconstruct their trajectories. On the virtual side, it uses a SUMO–CARLA co-simulation environment that mirrors vehicle flows and roadway geometry. The operational loop is: roadside cameras detect vehicles with YOLOv8/YOLOv11 and track their trajectories; GeoLane converts these trajectories into lane geometries in GPS coordinates; the resulting lane geometries and trajectories are injected into SUMO and then into CARLA via OpenDRIVE; and a meta-learning plus federated learning layer learns how to adapt lane detection parameters for each camera or location and share knowledge across locations without sharing raw data (Tamaru et al., 11 Jul 2025).

Within this architecture, GeoLane is the baseline “knowledge-based” lane detection algorithm executed at each roadside client. It takes vehicle trajectories projected to GPS coordinates as input, estimates lane count via histogram analysis, clusters trajectories into lanes with KMeans, fits lane centerlines with splines, estimates lane width from lateral variance, and generates lane boundaries by offsetting the centerline using normal vectors. GeoLane is controlled by pipeline hyperparameters governing smoothing, histogram thresholds, clustering settings, and related operations. A single global configuration performs poorly across heterogeneous scenes, including different camera angles, traffic densities, and road layouts. Meta-GeoLane addresses this heterogeneity by learning a mapping from scene context to task-specific GeoLane parameters rather than learning lane geometry directly (Tamaru et al., 11 Jul 2025).

A central misconception is therefore that Meta-GeoLane is itself the lane detector. It is instead a parameter generator for a non-differentiable detection pipeline. The lane geometry representation remains centerlines and boundaries in GPS coordinates; adaptation occurs through hyperparameter selection rather than through learned weights inside the detection pipeline (Tamaru et al., 11 Jul 2025).

2. GeoLane pipeline and the parameterization that Meta-GeoLane controls

GeoLane operates on vehicle trajectories derived from roadside video. Vehicles are detected in video frames using YOLO, and 2D pixel positions are projected to GPS coordinates through homography constructed from known image–GPS correspondences. Raw detections $(u,v)$ are transformed into $(x_{\text{gps}}, y_{\text{gps}})$, producing the trajectory representation used downstream (Tamaru et al., 11 Jul 2025).

Lane count estimation is performed through histogram analysis over mean lateral trajectory positions. Let $X = \{x_i\}$ denote the set of mean lateral positions across trajectories in a lane group. GeoLane constructs a histogram over $X$, applies Gaussian smoothing, and detects peaks. The detected peaks $\{p_1,\dots,p_k\}$ estimate both lane centers and lane number $k$. Meta-GeoLane controls parameters that affect this stage, including smoothing-related parameters and angle thresholds that influence grouping (Tamaru et al., 11 Jul 2025).

Given the inferred lane count $k$, GeoLane clusters trajectories in lateral space using KMeans,

$\hat{y} = \mathrm{KMeans}(X, \mathrm{clusters}=k).$

Each cluster is treated as a lane group. For each lane, points are sorted by longitudinal GPS coordinate and a spline is fitted,

$x(y) = \mathrm{Spline}(y; s),$

where the smoothing parameter $s$ is controlled by $(x_{\text{gps}}, y_{\text{gps}})$0. GeoLane therefore represents lane centerlines as piecewise-sampled splines rather than as dense pixel masks or end-to-end vector outputs (Tamaru et al., 11 Jul 2025).

Lane width is estimated from lateral spread,

$(x_{\text{gps}}, y_{\text{gps}})$1

where $(x_{\text{gps}}, y_{\text{gps}})$2 is the standard deviation of the lateral coordinates of assigned trajectories. Boundaries are then formed by offsetting the centerline along the spline normal,

$(x_{\text{gps}}, y_{\text{gps}})$3

Meta-GeoLane does not change this geometric representation. It alters the behavior of the histogram, grouping, clustering, and spline-fitting stages by producing scene-specific pipeline hyperparameters such as $(x_{\text{gps}}, y_{\text{gps}})$4, $(x_{\text{gps}}, y_{\text{gps}})$5, and potentially histogram bin sizes and peak-prominence thresholds (Tamaru et al., 11 Jul 2025).

This design makes Meta-GeoLane unusual relative to learned lane detectors. The learned component acts at the level of algorithmic control variables for a knowledge-based system. A plausible implication is that interpretability is preserved at the pipeline level, because the outputs of the meta-learner correspond to explicit detector parameters rather than latent lane codes.

3. Meta-learning formulation and architecture

Meta-GeoLane casts each camera or location as a task,

$(x_{\text{gps}}, y_{\text{gps}})$6

with its own scene context vector $(x_{\text{gps}}, y_{\text{gps}})$7, road geometry and traffic patterns, and weak labels $(x_{\text{gps}}, y_{\text{gps}})$8, which are reference “good” detection parameters derived from alignment with OSM/SUMO. The objective is to learn a function

$(x_{\text{gps}}, y_{\text{gps}})$9

such that the predicted parameter vector $X = \{x_i\}$0 approximates the scene-optimal parameter vector $X = \{x_i\}$1 across tasks. Meta-training is expressed as

$X = \{x_i\}$2

Unlike MAML-style gradient-based meta-learning, there is no inner-loop gradient step through the lane detection pipeline; adaptation is one-shot,

$X = \{x_i\}$3

The paper explicitly characterizes this as a black-box, data-free meta-learning approach because the downstream pipeline contains non-differentiable operations such as histogram peak detection, KMeans clustering, and spline fitting (Tamaru et al., 11 Jul 2025).

The supervisory signal is parameter alignment rather than backpropagated geometry error. The training loss is

$X = \{x_i\}$4

where $X = \{x_i\}$5 is the set of pipeline parameters. The paper states that this alignment loss is not backpropagated through the downstream lane detection pipeline; it independently supervises the meta-learner that generates candidate parameters for the black-box lane detection model (Tamaru et al., 11 Jul 2025).

Architecturally, Meta-GeoLane is a two-layer MLP with a shared hidden representation and multiple output heads. Given a scene feature vector $X = \{x_i\}$6, the shared trunk computes a hidden state $X = \{x_i\}$7, and separate heads produce individual parameters $X = \{x_i\}$8. The paper gives a representative bounded output head for the smoothing parameter,

$X = \{x_i\}$9

The inputs include scene-level descriptors such as statistics of trajectories, average speed, traffic density, and time-of-day. The outputs include at least histogram or smoothing-related parameters and angle or grouping thresholds (Tamaru et al., 11 Jul 2025).

Because inference is a single forward pass through a small MLP, deployment does not require task-specific fine-tuning. This supports the stated objective of generating near-optimal parameters for a new camera without retraining the full detection pipeline or requiring manual calibration.

4. Federated extension: FedMeta-GeoLane

FedMeta-GeoLane is the federated version of the same meta-learner. In the reported federation topology, roadside sensing units or camera sites act as clients and the central digital twin server acts as the server. At each communication round, the server sends the current global meta-parameter vector $X$0 to a subset or all clients; each client uses its local dataset of scene features and reference parameters to update $X$1 by minimizing local parameter alignment loss; clients return gradients or updated weights; and the server aggregates them in a FedAvg-like manner,

$X$2

where $X$3 is the local sample count for client $X$4. The paper emphasizes that no raw video or trajectory data are transmitted (Tamaru et al., 11 Jul 2025).

What is exchanged is narrow in scope: the server sends current global meta-learner parameters $X$5, and clients return gradients or updated $X$6. Images, trajectory points, and map data are not shared. In the experiments, the transferred model updates are around 0.2 MB. This distinguishes FedMeta-GeoLane from centralized meta-learning, where full video streams and files are uploaded to the server (Tamaru et al., 11 Jul 2025).

The reported communication figures are explicit. Baseline and centralized meta-learning require upload of full video streams and files totaling 427.3 MB per client, corresponding to approximately 3418 Mbps. FedMeta-GeoLane uploads only model updates and small files, reported as 5.6 MB upload and 0.018 MB download over 20 rounds, corresponding to approximately 47.2 Mbps. The paper reports this as over 98% reduction in communication overhead (Tamaru et al., 11 Jul 2025).

The federated formulation is not presented only as a privacy mechanism. In the reported experiments it also improves generalization. The article’s own interpretation is that federated aggregation better captures cross-client heterogeneity, which is consistent with the lower and more stable parameter alignment loss observed over federated rounds relative to centralized Meta-GeoLane (Tamaru et al., 11 Jul 2025).

5. Evaluation, deployment procedure, and limitations

The reported experiments use real-world data from four WisDOT roadside cameras on US 12/18 in Madison, Wisconsin: Todd Dr, Park St, west of Yahara River, and Monona Dr. Vehicle trajectories are obtained from YOLO detection and tracking, projected into GPS coordinates through homography, and aligned with OSM-derived map data for pseudo-ground-truth lane centerlines and lane counts. These sites are treated as four tasks or clients (Tamaru et al., 11 Jul 2025).

Three models are compared: GeoLane with fixed pipeline parameters; Meta-GeoLane with centrally trained black-box meta-learning; and FedMeta-GeoLane with federated training of the same meta-learner. On seen locations, the reported values are:

• GeoLane: $X$7, $X$8
• Meta-GeoLane: $X$9, $\{p_1,\dots,p_k\}$0
• FedMeta-GeoLane: $\{p_1,\dots,p_k\}$1, $\{p_1,\dots,p_k\}$2

On unseen locations, exemplified by Park, the reported values are:

• Meta-GeoLane: $\{p_1,\dots,p_k\}$3, $\{p_1,\dots,p_k\}$4
• FedMeta-GeoLane: $\{p_1,\dots,p_k\}$5, $\{p_1,\dots,p_k\}$6

The paper states that FedMeta-GeoLane further improves geometry by about 37.5% over centralized Meta-GeoLane and about 99% over baseline on seen locations, with lane width error as low as 2.65 m; on unseen locations it reduces total error by more than 50% compared to centralized Meta-GeoLane. Lane count loss remains non-zero for all methods, indicating persistent difficulty in correctly inferring lane number (Tamaru et al., 11 Jul 2025).

Qualitative results are aligned with the numeric results. On Yahara and Todd, the baseline captures rough geometry but shows poor lane boundaries and lane count; Meta-GeoLane improves lane shapes but still mis-segments some lanes; FedMeta-GeoLane produces better alignment of centerlines and boundaries. On Monona, all models miss the leftmost lane because of sparse traffic, though the meta-learning variants improve well-populated lanes. On Park, which contains complex curvature and diverging lanes, no model reconstructs geometry perfectly, but FedMeta-GeoLane yields more plausible and stable geometry than Meta-GeoLane (Tamaru et al., 11 Jul 2025).

Deployment is defined as a short calibration-and-inference procedure. For a new roadside location, the steps are: calibrate homography for the new camera; run YOLO-based detection and track vehicles for a short period such as 60 seconds; extract scene features $\{p_1,\dots,p_k\}$7; run the trained meta-learner to obtain $\{p_1,\dots,p_k\}$8; and apply GeoLane with $\{p_1,\dots,p_k\}$9 to detect lane centerlines and boundaries. Adaptation is fast because it requires only a single MLP forward pass and no gradient-based fine-tuning (Tamaru et al., 11 Jul 2025).

The limitations are equally explicit. Data sparsity causes lanes with very sparse traffic to be missed. Lane count estimation remains difficult under occlusion, merging, and low volume. Homography-based GPS projection is sensitive to calibration error. The current SUMO–CARLA integration does not dynamically model vegetation, buildings, or weather. Suggested future work includes adding scene semantics and topological priors, exploring end-to-end geometrical learning from images where feasible, improving robustness to sparse traffic and complex merging or weaving geometries, and enhancing digital twin fidelity with multiple scenarios and environmental conditions (Tamaru et al., 11 Jul 2025).

6. Related formulations and broader interpretations

In the cited materials, “Meta-GeoLane” appears both as a specific model name and as a broader conceptual direction. The most specific use is the Geo-ORBIT component just described: a scene-adaptive meta-learner over GeoLane hyperparameters (Tamaru et al., 11 Jul 2025). A broader use appears in work on map reconstruction from language and road manuals, which states that a conceptual system “Meta-GeoLane” would use meta-information such as manuals, regulations, road naming conventions, and geographic priors from OSM and local design rules. That paper augments SMERF by combining structured road metadata from OSM maps and lane-width priors retrieved from the Caltrans Highway Design Manual via RAG and LLaMA 3.3, then fuses those priors with polyline embeddings for lane-topology prediction (Tumu et al., 12 Jun 2025).

Other papers explicitly describe how their methods could inform a system like Meta-GeoLane. Gen-LaneNet argues for a geometry-guided anchor representation in a geometry-consistent coordinate frame and a two-stage framework that decouples 2D appearance from 3D geometry, reducing 3D label requirements and improving generalization on unfamiliar scenes and unseen illumination (Guo et al., 2020). TopoLogic proposes an interpretable topology-reasoning pipeline based on lane geometric distance and lane query similarity, using

$k$0

to mitigate endpoint shifts and improve lane-lane topology reasoning, which its authors present as a useful design pattern for a geometry-aware framework like Meta-GeoLane (Fu et al., 2024).

More recent work extends the design space further. TopoGPT is described as a geometry-prior, generative “lane LLM” trained on 3.3M map scenes, with a tokenizer that serializes lane graphs into discrete tokens and an autoregressive transformer that learns a prior over lane graph structures; the paper explicitly identifies this as a concrete instantiation of what might be called a Meta-GeoLane system (Fu et al., 30 Jun 2026). MapAgent, in turn, provides a blueprint for a meta-layer above base lane perception: a specification-aware Judge–Planner–Worker loop with explicit verification,

$k$1

selectively triggered on low-confidence tiles to produce specification-compliant lane maps at city scale (Xia et al., 3 Jun 2026).

Taken together, these works suggest a broader interpretation of Meta-GeoLane as a family of systems that place a learned or rule-informed adaptation layer above base lane geometry extraction. In the narrow Geo-ORBIT sense, that layer predicts scene-specific hyperparameters for a knowledge-based detector. In the wider literature suggested by adjacent papers, it can also denote the use of language-derived priors, geometry-consistent coordinate systems, interpretable topology reasoning, large-scale generative geometry priors, or specification-verification layers on top of perception.