HD Map Handbook

Preface

How this book came to be

We are living through the first decade in which machines move through the physical world on their own. The LiDAR got cheap. The compute got fast. The planners got clever. The part that did not keep up is quieter and less glamorous: the map. Every self-driving vehicle, delivery robot, and yard truck depends on a machine-readable description of its world, and producing that description is still the field’s bottleneck. This book is about that bottleneck.

HD mapping is a fragmented, intimidating field. The knowledge exists. It just does not live in one place. It is scattered across GitHub READMEs that assume you already know half of it, academic papers that assume you know the other half, and the institutional memory of the engineers who have already shipped an autonomous machine. Everyone who enters this field learns it the hard way, one half-understood source at a time.

I came into this field from the outside, and learning it was less like reading a textbook than assembling a jigsaw puzzle from conference papers, GitHub repositories, and scattered blog posts. I started writing down the explanations I wished I had. The notes began as a way to avoid explaining the same thing a second time; they became a book when they outgrew the READMEs they were correcting. It brings the field together in one place, organized around the reader’s developing mental model rather than the software’s internal architecture. Not “here is what Lanelet2 stores,” but “here is the problem Lanelet2 exists to solve, and by the time you meet the format you already know why it has to look the way it does.”

That is the one rule the book tries never to break: never explain a technology before explaining the problem it solves. Formats and tools only appear once you understand why they have to exist. By the time you meet Lanelet2, you already know the question it answers.

This is a living book, not an unfinished book. Some chapters are written; others are planned and visible in the table of contents. The whole book is revised as the field moves and as readers tell us what confused them, and some of what you read today will be rewritten. That is the cost of a book that keeps pace with the technology, and I consider it the right trade. I decided to publish it openly because the more people who understand the foundations of autonomous vehicles, the better; if you are curious about this field, I hope it saves you some of the time I spent piecing it together. And if you find an error or a gap, say so. The next reader benefits.

What you will be able to do

By the end of this Handbook, you should be able to look at an autonomous vehicle stack and understand what the map is doing, where its data came from, how it represents the physical world, how localization relates to it, how routing and behavior consume it, and where the pieces fit together. That is an honest promise: it will not make you a robotics engineer. It will give you the mental model the field is missing.

What this book is not

This is not an Autoware manual. It is not a Lanelet2 specification. It is not a robotics textbook. And it is not a tutorial for one particular autonomous vehicle. It is the layer between those things: an explanation of how the physical world gets represented, structured, and ultimately made useful to autonomous machines.

Why a book when the READMEs exist?

You could assemble this field the way most engineers do: one half-understood README at a time. It can be done. The READMEs are plentiful, the papers are free, and an expert is usually one forum question away. What none of those sources can give you is order. Each one assumes you already know the half it does not cover, so the learning path becomes a maze of assumed knowledge you can only detect by getting lost. A book’s real product is sequence: the guarantee that every idea arrives after the one it needs.

A living book is honest about what it does not know yet. It is the README that admits what it does not know, because it is written in public and revised as the field moves.

A note on conventions

A few markers recur throughout the book. They look like this.

Chapters also carry a species tag that tells you what kind of chapter you are in:

Handbookconceptual prose, the main threadWorkshophands-on projectsReferenceprecise lookups, specs, schemasVeer Studio Manualthe software itself

Errata and contact

The book grows in public; some chapters are written, others planned and visible. If you find an error or want to request a chapter, write to us through the contact page. We read everything.

Back to the HandbookNext: Reader’s Guide