The HD Mapping Workflow and Validation

Part I introduced the seven-stage pipeline from reality to motion. Parts II through V filled in the foundations. This chapter brings it together into a repeatable workflow, the actual sequence of steps you execute to go from a raw point cloud to a validated Lanelet2 map.

The workflow, step by step

1. Capture. Acquire a point cloud of the site. Vehicle-mounted LiDAR is the default for outdoor sites; handheld or drone fills the gaps. The deliverable is one or more raw point cloud files in LAS or PCD format.

2. Align. Register the scans into a single coordinate frame. SLAM produces the initial alignment; ground control points lock it to global coordinates. The deliverable is a registered point cloud, georeferenced to UTM or a local site frame.

3. Trace. Draw the vector layer on top of the point cloud. Trace lane centerlines, boundaries, stop lines, curbs, and crosswalks as linestrings. Most tools, including Veer Studio, provide snap-to-surface tracing that keeps vectors on the point cloud geometry.

4. Annotate. Tag every traced element with semantics. This linestring is a lane boundary. This one is a stop line. This polygon is a crosswalk. The deliverable is a semantically labeled vector layer where every element has a known type.

5. Connect. Build the topological graph. Define which lanelets are successors of which. Mark intersections. Add adjacency relations for lane-change maneuvers. The deliverable is a connected road network where a planner can find a path from any lanelet to any other.

6. Validate. Run automated checks on the map before export. Are all lanelets connected? Are any regulatory elements missing their referent? Are there orphan lanelets floating without topology? Does the map pass the Autoware schema validation? This step catches errors before the robot does.

7. Export. Write the validated map to the target format. For Autoware, this is a Lanelet2 .osm file. For simulation, this might be OpenDRIVE .xodr. For CAD integration, this might be DXF or SHP. The deliverable is a file that loads without errors in the target system.

Validation: catching errors before the robot does

Validation is not a checkbox at the end. It is a discipline that runs alongside the entire workflow. Every automated check that finds an error in your map is an error the robot will not have to survive in the real world.

Autoware defines a set of validation requirements, the vm-01 through vm-07 taxonomy, that every Lanelet2 map must pass before being loaded onto a vehicle.

vm-01: Schema compliance. The file is valid OSM XML, conforms to the Lanelet2 schema, and can be parsed without errors. This is the minimum bar. A file that fails vm-01 will not load.

vm-02: Geometry integrity. No duplicate points, no zero-length linestrings, no self-intersecting boundaries. Lane boundaries are continuous and smooth.

vm-03: Topology connectivity. Every lanelet (except terminal ones) has at least one successor. The road network graph is connected. No orphan lanelets float without topological relations.

vm-04: Regulatory completeness. Every stop line has a corresponding stop sign regulatory element. Every traffic light references the lanelets it controls. No regulatory element references a non-existent linestring or lanelet.

vm-05: Spatial consistency. Lane boundaries do not cross without a defined intersection. Adjacent lanelets share consistent boundaries. Speed limits and direction tags are spatially coherent.

vm-06: Real-world alignment. The map aligns with the point cloud to within the required accuracy. No vectors float in space disconnected from the geometry they are supposed to trace.

vm-07: Planner compatibility. The map loads into the target planner, a route can be computed from any lanelet to any other, and the planner does not produce warnings or errors.

Common mapping mistakes

After watching enough maps go through validation, a short list of the mistakes that cause the most problems:

• Orphan lanelets. A lanelet traced but never connected to the road network. It exists, it is valid, and no route will ever use it.
• Missing successor at intersections. The lanelet ends at the intersection boundary but has no successor. The planner cannot cross the intersection.
• Regulatory elements without referents. A stop sign that references a stop line ID that does not exist. The rule is present but unattached.
• Boundary mismatch. Two adjacent lanelets share a boundary in reality but have different linestrings in the map. The gap between them is a place the robot cannot navigate.
• Wrong direction tag. A lanelet tagged as one-way in the wrong direction. The planner routes the robot against traffic.
• Unregistered point cloud. The vectors were traced on a point cloud that was not georeferenced. The entire map is shifted relative to reality.

Every one of these is caught by at least one validation rule. The workflow exists so you catch them at step 6, not at step 7 when the robot is moving.

What comes next

With a validated map in hand, Part VII, From Map to Autonomy, shows where it goes: Autoware loads it, localizes and perceives against it, plans a route through it, and when the robot does not behave, you trace the failure back into the map.