AI3D-336 — “Too far from the edge line” delineator filter

Summary

What it does

Real delineators stand about 0.5–2 m outside the carriageway edge — that is their job. So if something the detector called a “delineator” stands tens of metres from every edge line the road model knows, it is almost certainly a stake in a field, not road furniture. The filter runs as the last post-processing step, after the stages that add delineators back (lattice, reject-rescue, rail half-posts), so it screens their output too — the rescue stage is where most far-off false positives come from.

One parsing change was needed to make this safe: the XML also contains ramp edges without a role label (features named like C_6, no “outer/inner” in the ID). The loader used to throw those away. In the newest Abschnitt 4/5 XML they are 28 of the 38 edge features — without them, real delineators along ramps would look up to 92 m “from the road” and be wrongly deleted. They are now part of the distance pool (and only of the distance pool; the on-road band gate is unchanged).

Why 30 m

The threshold was not guessed — it comes from measuring every previously-accepted delineator in the August production outputs against the newest XMLs, then checking the far ones by eye in the QC imagery. Two populations emerged with a gap between them:

Update 2026-08-20 (later): painted lane lines are now part of the measurement

The distance pool was extended from the edge features to ALSO include the XML’s painted lane-line families ("Center Lines" dash segments, "Central Axis", "Single-Side Central Axis") — knob edge_line.far_include_lane_lines, default on; new audit column edgeline_line_dist_m next to edgeline_edge_dist_m. Effect on the production outputs at the same 30 m cut: removals go 18 → 15, and the three no-longer-removed are precisely the likely-real ones — a rail half-post beside a marked-but-edgeless area (44.4 m → 4.6 m) and two of the three borderline junction posts in A1 segment 121 (35.8 → 28.3, 30.4 → 21.7). The A4/5 junction posts of segments 132–135 barely move — that infield has no lines of any family — so the 30 m default stands.

Update: the two-tier rule below is now implemented (default on)

Yes — but not on distance alone. The step7 XML already contributes its ramp edges (the roleless C_* features are in the distance pool), yet its ramp coverage has gaps, and real posts along unmapped ramp stretches measure 15–48 m. What separates those from field stakes at the same distance is road-context saturation (roadctx_n_sat, already in clusters.csv): a post beside an unmapped paved ramp sees hundreds to tens of thousands of saturated returns within 15 m; a stake in an orchard sees a handful. A candidate two-tier rule measured on the production outputs:

• Tier 1 — distance > 30 m: remove (current behaviour), optionally sparing high-saturation points (would save the three A1B0 junction posts at 30–48 m with 50k+ saturation).
• Tier 2 — distance > 15 m and saturation < 150: remove. Adds 12 kills across the three corridors (3 A45 + 8 A1B0 + 1 A1B1), all rescue-stage or isolated reflective hits in fields, while every confirmed junction/ramp post stays (their saturation is ≥ ~200).

Implemented as described (without the tier-1 saturation exemption — the lane-line pool already spares the high-saturation junction posts except the one still 39 m from every line). A stored saturation of 0 is treated as "not measured" and is never tier-2-killable — this keeps the tier inert on legacy outputs that predate the roadctx_n_sat column, verified on out_final. Rail half-posts stay tier-1-only (no per-row saturation record; they are anchored to detected guardrails anyway).

Results on real data

Validated two ways on Battlebox: (1) the post-pass applied to copies of the 2026-08-12 production outputs, and (2) full end-to-end detector runs on Abschnitt 1 (both branches, production config) and Abschnitt 4/5 segment 066 — both give the same removals.

caveat Segment 121 (A1 branch 0) is a motorway junction whose infield ramp is not in the XML. Two of its three removals (reflective_top at 35.8 and 47.9 m) could be real ramp posts — the only removals not clearly false. If recall there matters, check the crops or raise far_max_distance_m to 50 for that corridor.

Where to see the difference in the data

Three places, from coarsest to finest:

1. Run-level tally — post_pass_summary.json

Every detector run now reports the stage next to the other post-passes. From the Abschnitt 1 test run:

{
  "delineator_lattice": 0,
  "rescue_stage": 12,
  "rail_half_post": 67,
  "far_from_edge_line": 5   ← new
}

2. Per-detection audit — segment_*/clusters.csv

Two new columns at the end of every row (every cluster gets them, not just removed ones — so the decision can be audited or re-run with a different threshold without re-detecting):

A removed row reads: accepted=False, type= (empty), reason=far_from_edge_line, e.g. in the A1 test run, segment_048/clusters.csv cluster 40: edgeline_edge_dist_m=43.115, edge_filtered_from=rescue_stage.

3. Final deliverable — segment_*/verticalsigns.json

The removed detections are simply gone from the JSON (which is what downstream LAS fusion reads), e.g. signs2_A45 drops from 589 to 579 delineator entries.

Concrete places to look on Battlebox

Quick way to list every removal in an output tree:

grep -l far_from_edge_line segment_*/clusters.csv | while read f; do
  awk -F, 'NR==1{for(i=1;i<=NF;i++)h[$i]=i} $h["reason"]=="far_from_edge_line"{print FILENAME, $h["cluster_id"], $h["edgeline_edge_dist_m"]"m"}' "$f"
done

Tuning / turning it off

Both knobs live in the edge_line section of the config JSON (defaults shown):

{
  "edge_line": {
    "far_filter_enabled": true,
    "far_max_distance_m": 30.0,        // tier 1: distance alone
    "far_include_lane_lines": true,    // measure against painted lane lines too
    "far_tier2_enabled": true,         // tier 2: distance + no pavement nearby
    "far_tier2_distance_m": 15.0,
    "far_tier2_max_saturation": 150    // roadctx_n_sat below this = "no pavement"
  }
}

• No run7_lanes*.xml beside the segments → the stage logs a warning and does nothing.
• Re-running with a larger threshold restores previously removed rows (the original label is kept in edge_filtered_from); running twice with the same threshold changes nothing.
• Only type delineator is screened — signs, posts and gantries are never touched.

Technical appendix