Handoff: ingesting the asphalt-edge exchange files

Summary

Files

Folder on the shared drive (new, created 2026-09-04):

N:\02_Modelling\05_Rink\02_AI 3D modeling\03_Working folder\260702_ML_Abschnitt_1\260904_asphalt_edges_A1_seg060-064\

Videos and per-segment stills of the same data: N:\02_Modelling\05_Rink\02_AI 3D modeling\02_OUT\260716_videos\260904_asphalt_edges_A1_seg060-064\.

The lane model the edges were checked against: N:\02_Modelling\05_Rink\02_AI 3D modeling\03_Working folder\260702_ML_Abschnitt_1\260722_run7_line_width\run7_lanes_branch_000_20260722-092426.xml (same schema family, same geoshift).

Format

XML tree (only the elements you need)

HighwayData
├─ MetaData
│  ├─ CreationDate, Source, SoftwareVersion
│  └─ SchemaVersion            "1.1"
├─ Geoshift                    X, Y, Z  (metres; ADD to every coordinate to get absolute EPSG:25832)
└─ Features
   └─ Feature                  (×20)
      ├─ Type                  "Paving Edge"
      ├─ ID                    e.g. asphalt_edge_060_left_01   = asphalt_edge_<segment>_<side>_<run>
      ├─ LaneID                "0"  (not lane-bound)
      ├─ Lines/ NumberOfLines, Points/ NumberOfPoints   (always empty / 0 for this producer)
      ├─ Polylines
      │  └─ Polyline           (exactly one per Feature)
      │     ├─ ID              e.g. asphalt_edge_060_left_01-1
      │     ├─ LaneID          "0"
      │     ├─ RoadPoint       From, To   = station interval on the segment axis (m), informational
      │     ├─ Vertices
      │     │  └─ Vertex (×~400)  ID, X, Y, Z   (local metres, Z = surface height at the edge)
      │     ├─ Annotation      Display=false   (no label to draw)
      │     └─ Attributes
      │        └─ Attribute name="…" type="string|integer|float"  (see table)
      ├─ NumberOfPolylines     "1"
      └─ Splines/ NumberOfSplines   (empty / 0)

Attributes on every Polyline

Coordinates

• Local right-handed frame in metres. Absolute = local + Geoshift per axis. For this document the geoshift is X 694541.4428, Y 5386372.3686, Z 467.4083, i.e. absolute Easting/Northing in EPSG:25832 (ETRS89 / UTM 32N) and absolute height.
• Coordinates are rounded to 1 mm; the XML stores them as decimal text (str(float), dot separator).
• Z is the mean point-cloud height sampled on the road surface at the edge, so the polylines lie on the pavement, not at an arbitrary elevation.
• Vertex order follows increasing station. The run7 lane model uses the same geoshift, so both documents overlay without any transform.

JSON twin

{
  "metadata": {"creation_date": "…", "source": "…", "software_version": "…", "schema_version": "1.1"},
  "geoshift": {"x": 694541.4427999306, "y": 5386372.36858739, "z": 467.408348358761},
  "features": [
    {"type": "Paving Edge", "id": "asphalt_edge_060_left_01", "lane_id": "0",
     "polylines": [
       {"id": "asphalt_edge_060_left_01-1", "lane_id": "0",
        "road_point": [0.75, 102.75],
        "vertices": [[229.499, -117.989, -12.807], [229.714, -117.862, -12.802], …],
        "annotation": {"display": false},
        "attributes": {"segment": 60, "side": "left", "edge_class": "outer", "run": 1,
                       "station_start_m": 0.75, "station_end_m": 102.75, "length_m": 100.746,
                       "n_stations": 409, "measured_fraction": 0.971, "interpolated_fraction": 0.029}}
     ]}
  ]
}

Real excerpt (first feature, vertices 3–408 elided)

<Feature>
  <Type>Paving Edge</Type>
  <ID>asphalt_edge_060_left_01</ID>
  <LaneID>0</LaneID>
  <Lines/>
  <NumberOfLines>0</NumberOfLines>
  <Points/>
  <NumberOfPoints>0</NumberOfPoints>
  <Polylines>
    <Polyline>
      <ID>asphalt_edge_060_left_01-1</ID>
      <LaneID>0</LaneID>
      <RoadPoint><From>0.75</From><To>102.75</To></RoadPoint>
      <Vertices>
        <Vertex><ID>asphalt_edge_060_left_01-1-1</ID><X>229.499</X><Y>-117.989</Y><Z>-12.807</Z></Vertex>
        <Vertex><ID>asphalt_edge_060_left_01-1-2</ID><X>229.714</X><Y>-117.862</Y><Z>-12.802</Z></Vertex>
        …
        <Vertex><ID>asphalt_edge_060_left_01-1-409</ID><X>313.637</X><Y>-62.697</Y><Z>-9.031</Z></Vertex>
      </Vertices>
      <Annotation><Display>false</Display></Annotation>
      <Attributes>
        <Attribute name="edge_class" type="string">outer</Attribute>
        <Attribute name="interpolated_fraction" type="float">0.029</Attribute>
        <Attribute name="length_m" type="float">100.746</Attribute>
        <Attribute name="measured_fraction" type="float">0.971</Attribute>
        <Attribute name="n_stations" type="integer">409</Attribute>
        <Attribute name="run" type="integer">1</Attribute>
        <Attribute name="segment" type="integer">60</Attribute>
        <Attribute name="side" type="string">left</Attribute>
        <Attribute name="station_end_m" type="float">102.75</Attribute>
        <Attribute name="station_start_m" type="float">0.75</Attribute>
      </Attributes>
    </Polyline>
  </Polylines>
  <NumberOfPolylines>1</NumberOfPolylines>
  <Splines/>
  <NumberOfSplines>0</NumberOfSplines>
</Feature>

In the real file every element is on its own line with two-space indentation; the excerpt is condensed. Attributes appear in alphabetical order of name.

Ingestion procedure (any language)

Everything is reachable with plain tree navigation. The left column gives the XPath for the XML, the right column the equivalent path in the JSON twin.

Parsing notes

• Numbers are plain decimal text with a dot separator, no thousands separator, no exponent, at most 3 decimals for coordinates. Booleans are the literal text true / false.
• No XML namespaces, no DTD, no XSD, no entities beyond the standard five. A streaming (SAX-style) reader works: the vertex count per polyline is known from n_stations, but you can just append until </Vertices>.
• The JSON twin is a single object; vertices arrays are nested arrays, not objects. Both files were produced from the same in-memory data, so counts and numbers match exactly.
• Element order inside Polyline is fixed (ID, LaneID, RoadPoint, Vertices, Annotation, Attributes); inside Feature as shown in the excerpt. Consumers should still look elements up by name rather than by position.

Worked example and expected numbers

If your first vertex does not come out at E 694770.942 / N 5386254.380, the geoshift was not added (values around 230 / −118) or was subtracted (values around 694312 / 5386490).

Mapping to CAD / GIS

• Entity: one 3D polyline per Polyline element, vertices in document order, open (not closed). In DXF use a true 3D polyline (POLYLINE with the 3D-polyline flag, or a LINE chain), not an LWPOLYLINE, which would drop Z. In GIS use LineString Z (or LineString ZM with the station as M, taken from station_start_m + 0.25 m × index).
• Units and CRS: metres; after adding the geoshift the XY are EPSG:25832 (ETRS89 / UTM 32N) and Z is the absolute height of the LIDAR data (same vertical reference as the run7 lane model and the run3 point clouds of this dataset).
• Layer / class: the HighwayData class Paving Edge corresponds to CAD layer pPLC_Pflasterkante (HBW poster class 5). Recommended split by the edge_class attribute: outer (pavement / verge boundary) and inner (pavement edge at the central median), or by side for four layers.
• Colour key used in the renders (optional, for consistency): left outer cyan, right outer magenta, inner left green, inner right orange.
• Precision: keep coordinates as double precision. Working in the local frame (skipping step 7) and applying the geoshift as a CRS offset / block insertion point avoids large-number precision loss in tools that store single precision.
• Optional simplification: Douglas-Peucker with 2–3 cm tolerance reduces ~400 vertices to a few dozen per run without visible change; do it after ingestion if the target format prefers sparse geometry.

Relation to the run7 lane model

• The lane XML (run7_lanes_branch_000_20260722-092426.xml) is the same HighwayData family (schema 1.0 producer: no SchemaVersion, no Attributes). It carries the lane markings as Splines (cubic Bézier: Fit_Points + 2 Control_Points per span) and Lines (dashed segments), and cross-section Points.
• Same Geoshift as the edges document, so both overlay directly in the local frame.
• Typical geometry: outer edges lie 0.3–0.6 m outside the outermost solid marking; inner edges lie between the innermost solid markings and the median. This was checked visually for all five segments (see the renders in the videos folder).

Verification done

• done Document validated by the writer's own schema checks (no advisory warnings for Paving Edge).
• done All 20 polylines: 328–415 vertices, station intervals 0–104 m, measured fraction 0.905–1.000, no NaN, Z within the road surface range.
• done Visual overlay against the run7 lane model in Open3D and in rendered stills/orbits (edges track the pavement boundary through the curve).
• not done Independent geodetic check against a survey reference. The absolute frame is inherited from the LIDAR trajectory (run3 geoshift), not re-validated here.
• not done Ground-truth accuracy metrics for these five segments (a GT harness exists for Abschnitt 4_5 only).

Risks and open questions

• Class naming: Paving Edge (pPLC_Pflasterkante) was chosen because it is the poster's "pavement edge" polyline class. If the CAD side expects a different class for asphalt edges (e.g. a Fahrbahnrand layer), remap on the Type string; the geometry does not change.
• Segment overlap: consecutive segments are independent runs; their polylines meet at the segment boundary planes but are not stitched into one continuous line. Stitch on segment + side order if a single line per side is required (endpoints are within a few centimetres).
• Only five segments: this is a sample (segments 060–064 of 131 in branch_000). The full section can be produced the same way on request.
• Left/right convention follows the road-axis direction of the dataset (increasing station), not the driving direction of a specific carriageway.
• Vertex density: 0.25 m spacing is deliberate (no simplification). Apply Douglas-Peucker (e.g. 3 cm) yourself if a lighter geometry is wanted.

Provenance

Produced 2026-09-04 with iolabs-point-cloud-detection-asphaltedge (branch t3code/3abd1a9d, Jira AI3D-384) and the iolabs-point-cloud-modelling-export 0.10.0 writer (HighwayData schema 1.1). The normative schema description lives in that package's docs/xml_schema_1_1_spec.md (Bitbucket, ioholding); the tables above cover everything needed for this document. Questions: Miroslav Simko (iolabs).