The Vector Survey: Choosing Autoware Lanelet2

The Harbor Yard cargo tug boots up at the loading dock. Its LiDAR sees everything: the concrete pillar to its left, the retaining wall to its right, the faded white stop line ahead. Millions of points. Centimeter precision.

The planner asks one question: “Where can I go?”

The point cloud has no answer. It is a record of what the sensor saw. It is not a map a robot can drive on. To answer the planner, you need a vector layer: a mathematical description of lanes, boundaries, and rules that turns raw geometry into executable paths. The format you choose for that layer determines whether the tug threads the dock approach cleanly or hesitates at every junction.

The HD map landscape

There is no single HD map format. There are several families, and each was born from a different assumption about what autonomy is for. The format a highway simulator needs is not the format a robotaxi fleet needs, and neither is the format a warehouse robot needs. Before settling on one, know what is out there and who built it.

ASAM OpenDRIVE is the civil engineering lineage. A road is a reference centerline with lane offsets defined by clothoids, arcs, and splines. It is mathematically smooth, it is the standard for driving simulators like CARLA, and Baidu Apollo runs a modified version of it. It excels on highways. It is painful to hand-edit, because the geometry is parametric rather than stored.

NDS, and its successor NDS.Live, is the production delivery standard. Maintained by an automotive consortium and used by BMW, Mercedes-Benz, and Volkswagen, it is less a geometry model than a logistics format: how do you tile, compress, and stream petabytes of map data to millions of cars over the air, in incremental refreshes? Vendors like HERE and TomTom deliver through it. It solves fleet-scale distribution. It does not solve “one team building one site map by hand.”

Proprietary robotaxi maps are the closed world. Waymo, Zoox, Mobileye, and Pony.ai each maintain internal formats whose schemas you will never see. These maps are not just lanes. They bundle LiDAR reflectivity priors, 3D landmark fingerprints, and localization features into a single world model that is part product, part competitive moat. You consume them through an SDK (software development kit), if you can get access at all.

Occupancy and pointcloud maps discard the lane abstraction entirely. Instead of lanes and rules, they store what is occupied, what is free, and what is traversable. This is the domain of warehouse AMRs, mining trucks, and ROS navigation stacks running OctoMap or voxel grids. It is the right model when the vehicle moves through unstructured space and there are no lanes to follow because there is no road.

Lanelet2 is the open, planner-friendly lane graph. Originating at the Karlsruhe Institute of Technology¹ and adopted by Autoware, academic robotics labs, and a growing number of ROS-based industrial vehicle stacks, it represents roads as drivable segments bounded by explicit left and right polylines, carrying connectivity and traffic rules inline. It is the branch of the family tree built for teams that want to read, edit, and trust the map themselves.

Family	Who uses it	Born to solve
OpenDRIVE	CARLA, dSPACE, Apollo	Smooth highway geometry for simulation
NDS / NDS.Live	BMW, Mercedes-Benz, VW, HERE, TomTom	Fleet-scale delivery and OTA updates
Proprietary	Waymo, Zoox, Mobileye, Pony.ai	A closed world prior as competitive moat
Occupancy grids	Warehouse AMRs, mining trucks, ROS nav	Traversability in unstructured space
Lanelet2	Autoware, academic labs, ROS industrial stacks	Open, editable lane graphs for planning

These families answer different questions. OpenDRIVE answers “how do I simulate this road at speed.” NDS answers “how do I ship this map to a million cars.” Proprietary maps answer “how do I encode everything my fleet has learned.” Lanelet2 answers the question Harbor Yard is actually asking: how does a small team build, edit, and trust a navigable map of one site, down to the centimeter.

That narrows the field. Among the formats that still model roads as lanes rather than free space, there are two fundamentally different ways to draw a lane, and the choice between them decides whether your robot stops at the dock or hits the pillar.

Implicit vs. explicit: two ways to represent a road

Every vector format for road networks falls into one of two camps.

Implicit (centerline). You define a single line down the middle of each road. Lane width, curb position, roadside boundaries: everything else is derived as an offset from that centerline. OpenDRIVE works this way. So does a basic OSM way tagged highway=service. It is compact, it is the standard for driving simulators, and it works well on highways where lanes are uniform and junctions are predictable.

The problem is the offset. At a complex intersection, there is no single unambiguous centerline to offset from. At the Harbor Yard dock approach (a 3-meter-wide lane squeezed between a concrete pillar and a retaining wall), an offset calculation that is off by 30 centimeters puts the robot into the pillar. The planner cannot see the pillar. It only sees the math.

Explicit (dual border). You define the left and right boundaries of every lane as independent linestrings. Nothing is derived. The boundary is stored, not computed. Lanelet2 works this way. The robot always knows the exact edge of its drivable space because that edge is a first-class object in the map.

Format	Style	Best use case
ROS 2 waypoints	Point list	Scripted paths, simple loops
OpenDRIVE	Implicit centerline	Highway simulators
OSM	Implicit / semantic	Broad road network layout
Lanelet2	Explicit dual border	Safety-critical planning in dense sites

Why Autoware Lanelet2

Lanelet2 is both a data format and a C++ software framework at the center of the open autonomy stack. The format defines how lanes, boundaries, and rules are structured. The framework provides the modules (routing, traffic rule interpretation, map matching) that turn that structure into something a planner can execute. Autoware, the open-source autonomous driving platform, reads Lanelet2 maps directly and extends the standard with requirements designed for real-world deployment on controlled sites.

Standard Lanelet2 gives you lanes, boundaries, and regulatory elements. Autoware adds mandatory constraints: elevation attributes on every node so the perception stack can find objects in 3D space, traffic lights represented as LineStrings with strict orientation rules, turn_direction attributes so the vehicle signals its intent at intersections, and two roadside subtypes that encode spatial policy for parking and pedestrian clearance.

Try this

[5 min] The Harbor Yard dock approach: compare a centerline trace to an explicit dual-border lanelet.

1. Trace a single line down the center of the dock approach, from the loop road to the loading bay. This is your implicit path. Notice what the robot does not know: its distance to the concrete pillar on the left, its distance to the retaining wall on the right.
2. Now trace two separate lines: one along the left curb, one along the right pillar edge. Bind them into a single lanelet with a direction of travel.
3. Ask yourself: which representation lets the planner calculate lateral tolerance? A centerline has zero width. A lanelet has volume. That volume is what keeps the cargo tug out of the pillar.

This is not a thought experiment. It is the single most important design decision you will make before you draw your first vector.

Footnotes

1. Lanelet2 was developed at the Karlsruhe Institute of Technology (KIT) and the FZI Research Center for Information Technology. The defining reference is Poggenhans et al., “Lanelet2: A High-Definition Map Framework for the Future of Automated Driving,” 2018. https://www.mrt.kit.edu/z/publ/download/2018/Poggenhans2018Lanelet2.pdf ↩