osmium-tool is the command line front end for OpenStreetMap data

One binary in front of a library, and why that matters

osmium-tool is a multipurpose command line tool for working with OpenStreetMap data, based on the Osmium library, and it is the practical counterpart to libosmium, which provides the object model and the file format support. The split is the design. Libosmium gives you a way to read an OSM file into typed objects, and the tool gives you a set of operations over that data without requiring you to write C++. The README describes the tool as multipurpose, and the official site and manual live at osmcode.org, with man pages shipped in the man directory of the repository. For a data pipeline this is the useful shape, because the operations that appear again and again, converting between formats, filtering by area, extracting references, checking file contents, are exactly the ones you would otherwise script by hand. The project is a single program rather than a library with bindings, which is the main limitation to be aware of when choosing it.

The dependency list is the real build story

You need a C++17 compliant compiler, and then a specific set of libraries with minimum versions. Libosmium at 2.23.1 or newer, Protozero at 1.6.3 or newer, NLohmann JSON at 3.0 or newer, boost-program-options at 1.55 or newer, bz2lib, zlib and Expat. LZ4 is optional and only needed for LZ4 PBF compression, and Pandoc is optional and only needed to build the documentation. Most of these are available through the package manager, with Debian and Ubuntu names such as libosmium2-dev, libprotozero-dev, nlohmann-json3-dev, libboost-program-options-dev, libbz2-dev, zlib1g-dev, libexpat1-dev and liblz4-dev, and Fedora names such as libosmium-devel, protozero-devel, boost-devel, bzip2-devel, zlib-devel and expat-devel. The README is direct about the catch, saying to check the versions, and that if the packaged version is not new enough you will have to install from source, and that this is most likely the case for Protozero and Libosmium. On macOS many of the libraries are available through Homebrew, and on Windows through vcpkg.

Building from source, and the sibling clone trick

Osmium uses CMake for its builds, and the Linux and macOS sequence is a standard out of source build. The README also mentions ccmake, which is CMake with a text interface, as optional if you want to change the settings. Build type is chosen with -DCMAKE_BUILD_TYPE=type, with the possible values being empty, Debug, Release, RelWithDebInfo, MinSizeRel and Dev, and the default is RelWithDebInfo. CMake also looks for the Libosmium and Protozero libraries in the same directory as the Osmium repository, which gives you a way to build against the newest versions of all three. The README shows that arrangement, cloning the three projects side by side:

mkdir work
cd work
git clone https://github.com/mapbox/protozero
git clone https://github.com/osmcode/libosmium
git clone https://github.com/osmcode/osmium-tool

That is the path to take when your distribution's packages are too old, and it is also how you work on the library and the tool together. The repository tree shows the same emphasis, with a cmake/ directory of modules, src/ for the tool itself, a man/ directory, bash_completion/ and zsh_completion/ directories, scripts/, a test/ directory, and the export-example-config/ and extract-example-config/ directories that hold sample configuration.

Tests, man pages and a long single maintainer history

The test suite is driven by ctest, which you run in the build directory after building, and more extensive tests of the libosmium I/O system can also be run, with instructions in the test/io/Makefile.in. The man pages need pandoc, and if the pandoc command was found during the CMake config step the man pages are built automatically, which is a nice touch since it means the documentation follows the code without a separate step. The project is maintained by Jochen Topf, and the copyright line reads Copyright (C) 2013-2026, which tells you this is a long-running project with a single consistent author rather than a rotating set of contributors. The licence is the GNU General Public License version 3, with the full text in LICENSE.txt. There is a CONTRIBUTING.md, a CHANGELOG.md, a .clang-tidy configuration, an iwyu.imp file for include what you use, and a fix-formatting.sh script, so the repository has the tooling of a project that expects contributions and enforces consistency on them.

What to expect from the version numbers

The release history shows a steady cadence with occasional larger jumps. Version 1.19.0 was published on 2026-01-18, 1.18.0 on 2025-03-17 and 1.17.0 on 2025-01-14. Two things are worth reading off that list. The first is that a minor version bump here can carry a lot of format handling changes, since the tool's job is precisely to keep pace with what appears in OSM extracts, so a new minor version is often something you want rather than something to avoid. The second is the gap between 1.17.0 in January 2025 and 1.18.0 in March 2025, which shows the project does not release on a fixed schedule. The repository is not archived and the last push was on 2026-10-19, so the code is active even where the tags are sparse, and the CHANGELOG.md in the repository is where the detail between releases will be.

Editorial conclusion

Adopt osmium-tool when you script against OpenStreetMap extracts and want a single binary that reads and writes the formats the ecosystem uses, rather than hand-rolling a parser. Do not adopt it if you need a Python or Java library, since this is a command line tool, and expect to install a stack of development packages first. Verify first that the packaged Libosmium and Protozero versions on your distribution are recent enough, because the README warns that the distributed versions are often too old and you will have to build from source, and that the man pages need pandoc at configure time.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. osmcode/osmium-tool on GitHub
3. Project website
4. README
5. Releases