How Autonomous Vehicles Use Maps

You have spent the last six Parts building an HD map. You captured a site, aligned it to a reference frame, traced every lane and stop line, and wired regulatory elements into a behavioral contract. The map is precise, validated, and stored in a .osm file. Now what?

The answer depends on which robot opens it. Every autonomy stack reads maps differently. They do not agree on file formats, on coordinate conventions, on which elements matter and which are ignored. A map built for one stack will fail silently in another, not because it is wrong, but because the stack was never expecting it.

This chapter surveys the landscape: what the major stacks expect, why those expectations differ, and why the rest of this book pins its practice to one of them.

The map is an input, not the answer

A Lanelet2 map is a structured description of a place. It contains lanes, boundaries, regulatory elements, and topology. What it does not contain is a driving policy. The map says “this is a lane, it goes this direction, and this stop line has a rule attached to it.” The autonomy stack decides what to do with that information.

That separation is the reason different stacks consume different maps. Each stack has its own architecture, its own data structures, and its own assumptions about what the map will provide. The map format is not a neutral interchange. It is a contract between the map builder and the stack, and the contract is different for every stack.

The major stacks and what they expect

Autoware (Lanelet2). Autoware¹ is the open-source autonomy stack maintained by the Autoware Foundation. It reads Lanelet2 maps stored as OSM XML, the same format OpenStreetMap uses, extended with Autoware-specific tags for detection areas, virtual stop lines, and other behaviors the stack needs. Lanelet2 is the only supported map format. There is no OpenDRIVE importer, no proprietary fallback. If you are deploying on Autoware, you are building Lanelet2. That clarity is why this book chose it.

Apollo (OpenDRIVE, plus proprietary layers). Baidu’s Apollo stack, widely deployed in Chinese autonomous driving programs, consumes OpenDRIVE as its primary map format. OpenDRIVE describes roads as a network of reference lines with lanes attached laterally, a different model from Lanelet2’s lanelet-centric approach. Apollo layers proprietary extensions on top of OpenDRIVE for HD semantic data: lane markings, traffic signs, and curb geometry that OpenDRIVE alone does not encode. The format is open; the extensions are not.

Tesla (proprietary, vision-derived). Tesla’s Autopilot and FSD stacks do not consume a pre-built HD map in the traditional sense. The vehicle builds a local map from camera and sensor data in real time, drawing lane lines, identifying obstacles, and inferring road topology from vision alone. There is no .osm file, no vector editor, no map builder curating lanelet boundaries at a desk. The map is a live reconstruction, and its format is internal to the vehicle. This approach is philosophically opposite to the one this book teaches. It also means that when Tesla’s stack makes a mistake, there is no map to debug. The error is in the perception pipeline, not in a lanelet that can be inspected and fixed.

Waymo (proprietary, sensor-fused). Waymo builds and maintains its own HD maps using a custom sensor-fusion pipeline. Their maps are believed to combine pre-surveyed geometry (from LiDAR scans of their operational domains) with real-time sensor updates. The format is proprietary. The map-building tools are proprietary. Nothing about the Waymo map pipeline is public. It is the most capable stack and the least accessible to anyone outside the company.

There are others: Cruise, Zoox, Motional, and a dozen more. Every one of them consumes a map format that is either proprietary or derived from OpenDRIVE. None of them expose their loader code. None of them let you see the map the way the robot sees it. Autoware does. That is why it is the reference stack for this book, and that is why the next three chapters are about it alone.

What Autoware needs from a Lanelet2 map

Autoware expects certain things from every map it loads. You have been building toward these expectations since Part V without naming them explicitly. Now it is time to name them.

A valid projection. Every Autoware map must be projected from geographic coordinates (latitude, longitude, altitude) into a local Cartesian frame. The loader reads the projection parameters from map_projection_loader and applies them to every point in the map. If the projection is missing or wrong, the map loads in the wrong place. Chapter 33 covers the loader and its expectations in detail.

Centerlines with direction of travel. Every lanelet must have a centerline that defines the path a vehicle follows through the lane. The centerline is not optional. Without it, the planner cannot generate a trajectory, and the vehicle will not move.

Regulatory elements that reference physical geometry. Stop lines, speed limits, and detection areas must be wired to lanelets through regulatory elements. An untethered stop line is invisible to the planner. Chapter 21 covered how to build these contracts. The loader will parse them without complaint, but if the references are broken, the planner ignores them.

Topology that connects. Every lanelet must declare its successors: which lanelets a vehicle can legally transition into. Topology is what turns a collection of lane segments into a navigable graph. Without it, the planner cannot find a route from A to B, even if the geometry is perfect.

Why Lanelet2, and why now

Lanelet2 is not the most expressive format. OpenDRIVE handles elevation profiles and road banking more naturally. Proprietary formats embed sensor models and live traffic data that Lanelet2 does not attempt to represent.

Lanelet2’s advantage is that it is open, it is simple enough to inspect by hand, and it is the format the largest open autonomy stack actually reads. When something goes wrong, you can open the .osm file, find the lanelet, and see what the robot sees. That is a debugging superpower. No other format gives you that.

Try this

[10 min] The rest of this Part is about Autoware. Before diving into the loader, take stock of what you know.

1. Open the Lanelet2 map you built for Harbor Yard in Parts V and VI.
2. List the elements the loader will extract: lanelets, areas, regulatory elements, centerlines.
3. For each element, ask: does this element answer one of the four questions (where am I, what is around me, where can I go, what am I allowed to do)? If an element serves none of them, it should not be in the map.

The next chapter opens the loader and watches what happens when it reads your map for the first time.

Footnotes

1. The Autoware stack description across this Part follows the Autoware Foundation’s deep-dive lecture, which walks through sensing, localization, perception, planning, and control. https://youtu.be/XdYMcmwVv8g ↩