Grounding the Path: Tracing Reality in the Pointcloud

The shared center border is the highest-stakes geometry in the map. It is the line that divides a lane from oncoming traffic, and if it drifts, the vehicle’s drivable space drifts with it. At Harbor Yard, the access road where vehicles enter and leave the yard runs two-way, and the cargo tug shares a center border with traffic moving the opposite direction. An editor who traces that border from memory, on a blank canvas, places it where it “looks right.” The tug, trusting the map, then runs however many centimeters off the true dividing line. Whether that offset matters depends on the lane width, the vehicle’s track, and the margin the planner keeps between the drivable region and the border. But the shared border is exactly where margin runs out, because on the far side of it is not a curb. It is oncoming traffic.

This is the grounding problem. A vector placed on a blank screen is a creative act. A vector traced from a LiDAR return is evidence. In HD mapping, the difference between the two is not aesthetic. On a shared border with oncoming traffic, it is the difference between a vehicle that stays in its lane and one that does not.

Why grounding matters: the localization contract

Every autonomous system answers “Where am I?” by matching live sensor returns to features stored in the map. When a LiDAR pulse hits a curb at Harbor Yard, the system compares the position of that return to the position of the curb in the vector map. If the two align, localization confidence goes up. If they diverge, the system begins to doubt itself.

Grounding is not about making the map look good in the editor. It is about ensuring that the map and the world agree, down to the centimeter, so the localization engine never has to guess.

Tracing the paint: snapping to the brightest return

Tracing a road marking from a point cloud is not a visual approximation. It is a requirement to snap every vector node to a high-intensity LiDAR return.

At Harbor Yard, weathered asphalt creates intensity ghosting: the paint is faded, and the LiDAR returns are noisy. You snap nodes to the brightest returns within the point cloud because those are the most reflective, most verifiable edges of the marking. When the vehicle’s sensors encounter that same marking, those bright returns are what they will see. The vector must align with the physical feature the sensor will detect, not the feature the editor remembers from the site walk.

The elevation mandate: why 2D vectors break Autoware

Standard Lanelet2 makes elevation optional. Autoware makes it mandatory. Every node in the map must carry an ele attribute defining its absolute 3D position, and the stack reads it for more than one reason. The traffic light recognizer uses ele, together with height, to know how high above the road to search for a signal. Path planning is largely 2D, but elevation becomes essential the moment two roadways share the same XY at different heights: an overpass, a multi-level garage, a ramp rising above a lower lane. Without ele, the planner cannot tell a bridge from an intersection, and the routing graph cannot tell which lanelets actually connect.

The confusion between ele and height is not carelessness; it is a seam in the format’s history. Lanelet2 inherits the OSM data model, and OSM was built as a 2D consumer street map where centimeter elevation was never first-class, so elevation entered the format as an optional tag rather than a core coordinate. Autoware then has to harden that and mandate ele on every node, because a robot localizing in 3D cannot treat Z as optional. height arrived separately, from the perception side, to describe an object’s vertical extent for bounding boxes. Two different vertical needs, absolute position and object scale, landed on a format whose ancestor cared about neither. Swap them, and the recognizer looks for a traffic light at the correct XY but the wrong elevation, where there is nothing to find.

Local frames: anchoring the map to the site

Chapter 5 introduced the local site frame as a concept: pick an origin, measure in meters, agree on the axes. This section is about the format mechanism, the tags Lanelet2 provides when a site actually uses one.

Most Autoware maps are georeferenced: their nodes carry real latitude and longitude, and those global coordinates are the source of truth the vehicle localizes against. That is the default, and for any site with a survey or a GNSS capture it is the right one. But not every site is georeferenced. A small yard with no survey markers and no reliable GNSS can still be mapped, by building a self-consistent map anchored to one fixed point at the site, a dock corner or a bolt set in concrete, and measuring every node in meters from that origin. For those sites, Lanelet2 and the Autoware OSM parser offer local_x and local_y tags that store position locally instead of as latitude and longitude.

The OSM format still requires a lat and lon on every node or the file will not load, so even a purely local map carries them. Their values can be anything, including zero, because whenever local_x and local_y are present the parser reads those for position and treats the lat/lon as placeholders. Elevation works the same in both modes: it always comes from the ele tag.

The choice between a global frame and a local one comes down to where the site’s ground truth lives. A georeferenced map inherits its accuracy from the survey or capture that produced its coordinates. A local map inherits its accuracy from the benchmark at its origin, and it stands on its own as long as every layer agrees on that origin. What matters is not which frame you pick, but that you pick one and keep the whole map inside it.

Try this

[10 min] Verify the Z-alignment of a curb at the Harbor Yard entrance.

1. Pick a linestring that represents a physical curb in your map. Select one node on that linestring.
2. Find the ele attribute on that node. This is the Z coordinate the map claims for that point in space.
3. Now look at the same location in the point cloud. What is the Z coordinate of the nearest ground return?
4. If the two numbers differ, the vector is floating. Adjust the node’s ele value until it matches the point cloud.

This exercise catches the most common grounding failure before the robot does. A floating vector is a promise the world will not keep.