Agent handoff 1 / 4 self-contained — no vault access needed

Implement guardrail detection — new repo, KIRIOLL pipeline

2026-07-10 · for a fresh implementation agent on a machine with repo + Nexus access, without the knowledge vault · all research findings are inlined below

Continuation target: create a new repo and implement a geometric (label-free) guardrail detector for highway MLS segments: trajectory-corridor crop → per-station vertical-profile signature → clustering + along-road continuity tracking → guardrail polylines + type stub, exported as XML. Reuse the existing iolabs-* packages from Nexus wherever possible. Machine learning is explicitly not the first route — verified literature reaches ~0.91–0.96 precision with pure geometry, CPU-only.

Project context (inlined)

Pipeline: LAS highway scans → trajectory detection → segments cut along the road axis (numpy .npz per segment; attributes XYZ + laser intensity + RGB) → per-segment detectors → XML vectors for CAD. Lane-marking detection already works this way (intensity filter + geometric line modelling).
Your input: segment point clouds + division planes (output of iolabs-point-cloud-segmentation-trajectory) + road-axis spline (trajectory packages / iolabs-geometry-geometry splines). Road-surface points + meshes also exist per segment (output of iolabs-point-cloud-filtering-surface).
Data prerequisite: ask Miro to ship 3–5 sample segments from "Abschnitt 1" (the German Autobahn test section) incl. trajectory + surface outputs. Data does not live in the repos.
A sibling repo exists: 3dai.iolabs.imageanalyzer.guardraildetection — the 2D cross-section route (renders 0.2 m-thick slabs perpendicular to the axis at ~300 px/m, ±30 m horizontal × ±4 m vertical; segmentation-first design with a dice-focal U-Net on 256 px crops; guardrail-type classification from profile shape against DXF reference profiles of 5 European systems). Your repo is the 3D geometric detector. Coordinate, don't duplicate: your rail positions along the axis become that repo's input for type classification.

Research findings (inlined — adversarially fact-checked 2026-07-07)

Confirmed, 3-0 verification votes unless noted:

Three independent label-free pipelines work on real highways: (a) trajectory buffer → geometric filters + statistical outlier removal → verticality → DBSCAN clustering [Yue 2021]; (b) Difference-of-Normals segmentation → vertical-profile filtering → point re-population → along-road tracking [Hou 2022]; (c) per-scanline sweep segmentation + feature-point tracing of the rail's continuity [Jiang 2016].
Accuracy: 95.6% / 95.5% precision with 97.9% / 100% length coverage on two Massachusetts state routes [Hou 2022]; W-beam P/R/F1 = 0.91/0.75/0.83 vs concrete barriers 0.76/0.67/0.71 on 9.4 km of Spanish highway MLS (82.7M points) [Vidal 2020]. Steel rails are consistently easier than concrete (walls look like other walls).
Corridor numbers to start from: lateral ≈ 2–9 m from the axis, height cap ≈ 2 m, ~5 m station windows; reduced 82.7M → 3.4M points (96%); full pipeline 8.8–24.7 min/cloud in Python on an i5 with 6 GB RAM [Vidal 2020]. No GPU anywhere.
Type classification: the strongest 2D result renders cross-sections (frontal view, 1 cm/px reflectance, ~10 m deep slabs) and runs YOLO: AP 0.98 concrete / 0.91 metal barrier over 1,306 km of Croatian highways [Brkić 2022] — chosen explicitly because vertical objects collapse in top-down view. This is the sibling repo's territory; expose a hook for it.

Refuted claims — do NOT build on these:

"Works without the trajectory/axis input because barrier geometry is norm-standardized" — rejected 0-3. The axis is load-bearing; pipelines are parameter-heavy and degrade under occlusion.
"Proven at network/production scale" — rejected 0-3. Best method validated on two routes only. Treat published numbers as feasibility, not a production guarantee.

Open gaps: cable barriers have no verified published method (thin cables, sparse returns) — detect-and-flag only in v1; vegetation occlusion is the main recall killer (lit. recall ≈ 0.75) — plan multi-pass tracking across gaps; corridor/height parameters must be re-tuned for German RAL-standard cross-sections, not copied from Spanish/US papers.

Nexus packages to reuse

Private index: https://nexus.iolabs.ch/repository/pypi-private/simple (configure in [tool.uv.sources] / [[tool.uv.index]] — copy the block from the 3dai.lanefinder repo's pyproject.toml). Update flow: uv lock --upgrade-package <pkg> && uv sync (add --refresh if metadata is stale). Naming is flat: distribution iolabs-point-cloud-* → import iolabs_point_cloud_* (exception: iolabs.common stays dot-namespaced).

Package (Nexus)	Use for
`iolabs-point-cloud-segmentation-trajectory`	Segment clouds + division planes (input format)
`iolabs-geometry-geometry`	3D splines (axis), planes, distances, cropping, station/offset transforms
`iolabs-point-cloud-filtering-clusters`	DBSCAN-style clustering + density filters
`iolabs-point-cloud-filtering-surface`	Road surface / height-above-road reference
`iolabs-point-cloud-modelling-export`	XML export (mirror the lines schema)
`iolabs-geometry-visualization` · `iolabs-point-cloud-las-tools` · `iolabs-common`	QC overlays, LAS IO, utils (`memory_guard`)
`io_orchestrator.ray_step`	Wrap the detector as a Ray pipeline step (IN/OUT params, logging, retry)

Suggested new repo/package: 3dai.iolabs.pointcloud.guardrails / iolabs-point-cloud-detection-guardrails — confirm the remote/org with Miro before creating.

Algorithm to implement

Corridor crop: transform the segment cloud to station/offset/height coordinates around the road axis; keep |offset| ≈ 2–9 m, height ≤ ~2 m above road level. Process in ~5 m station windows.
Candidate filter per window: statistical outlier removal → covariance/eigen features (verticality, linearity/planarity) → keep rail-height band points forming long thin road-parallel structures.
Cluster + trace: DBSCAN within windows; link clusters across windows by continuity (offset + heading). Bridge only short gaps; record every gap span in the output.
Vectorize: fit polyline/spline per rail run (left/right/median), attach a per-station height profile.
Type stub: heuristic W-beam vs concrete from the cross-profile (rail band + periodic posts vs continuous wall ~0.8–1.2 m); flag suspected cable barriers. Leave a clean interface for the 2D classifier from imageanalyzer.guardraildetection.
Export: XML via iolabs-point-cloud-modelling-export.

Verification

No code exists yet — nothing has been run. Build QC in from day one: per-segment overlays via iolabs-geometry-visualization.
Hand-count guardrail runs on the 3–5 sample segments for ground truth; report precision, recall, and length-coverage. Literature bar: precision ≥ 0.9 (W-beam), expect concrete ~0.7 and recall dips under vegetation.

References (inlined)

Hou, Ai & Boudreau (2022). Network-Level Guardrail Extraction… J. Comput. Civ. Eng. 36(6). DOI 10.1061/(ASCE)CP.1943-5487.0001049
Vidal, Díaz-Vilariño, Arias & Balado (2020). Barrier and Guardrail Extraction and Classification from Point Clouds. ISPRS Archives XLIII-B5. copernicus.org
Yue, Gouda & El-Basyouny (2021). Automatic Detection and Mapping of Highway Guardrails from Mobile Lidar. IGARSS 2021. ieee 9553055
Jiang, He, Liu, Ai & Lang (2016). Corrugated beam guardrail detection from MLS. IEEE ITSC 2016. ieee 7795762
Brkić, Miler, Ševrović & Medak (2022). Roadside Feature Detection from Lidar Road Cross-Section Images. Sensors 22(15):5510. mdpi.com

Public research briefs (work from any machine): guardrails brief · all 30 sources.

Conventions

UV project, Python ≥3.11, same lint/test setup as other 3dai.iolabs.* repos (look at one).
Release = version bump → uv build → publish to Nexus pypi-private → commit tagged with the Jira issue (project AI3D).
No vault on this machine: report findings/decisions back to Miro in your final summary; he files them into the knowledge base.