Boost.Geometry gives you concepts, not just algorithms, which is the harder half

The C++17 move is the first thing to plan around

The very first line of the project documentation is a caution, and it is about the language standard rather than about geometry.

It says that Boost.Geometry in Boost 1.93 deprecates support for C++14 and will require C++17 from Boost 1.95 onwards, with a pointer to a discussion thread for the reasoning.

That is a two-release window of warning. If your build is on C++14 today, you can take Boost 1.93 but you should be planning the C++17 move now, because the library will not accept a C++14 configuration from 1.95. For a library with this many users, a standard bump is a coordinated change rather than a surprise, and the fact that it is announced in the README with a discussion link suggests the reasoning is public and worth reading before you decide how to respond.

The description line carries the same information in a different form: Generic Geometry Library, Requires C++14 since Boost 1.75. So the floor moved up to C++14 in Boost 1.75 and moves up again to C++17 in 1.95. If you jumped a Boost release in the last few years and never noticed the floor, your compiler flags are probably lower than you think.

This is also the main practical upgrade cost of the library, and it is worth putting next to the rest of the decision before you look at anything else.

Concepts are the product, and algorithms hang off them

Boost.Geometry is part of the collection of the Boost C++ Libraries, and it defines concepts, primitives and algorithms for solving geometry problems. It is a C++14 header-only library, so there is nothing to build and nothing to link.

The order of those three nouns is the design. Concepts come first, which means the library is built around the idea that a point is not a fixed type but a family of types satisfying a concept. A custom point type, a custom box, a custom linestring, a custom polygon, a custom triangle all work with the same algorithms as the built-in ones, provided they meet the concept's requirements.

That is what makes this a generic geometry library rather than a collection of geometry functions. The alternative design, where a library provides a Point class and a set of functions taking it, is simpler to write and locks you into that class. Boost.Geometry asks more of you up front, and gives back the ability to use your own types.

The example directory shows how far that goes. There are numbered examples for the basic primitives, 01_point_example.cpp, 02_linestring_example.cpp and 03_polygon_example.cpp, then an example of using Boost.Geometry alongside another Boost library in 04_boost_example.cpp, then overlay examples for polygon and linestring against polygon in 05_a and 05_b, transformation examples in 06_a and 06_b, and graph route examples in 07_a and 07_b.

Then there is a run of c-prefixed examples, and the naming is the documentation. c01_custom_point_example.cpp, c02_custom_box_example.cpp, c03_custom_linestring_example.cpp, c04_a_custom_triangle_example.cpp and c04_b_custom_triangle_example.cpp, c05_custom_point_pointer_example.cpp, c06_custom_polygon_example.cpp, c07_custom_ring_pointer_example.cpp, c08_custom_non_std_example.cpp, c09_custom_fusion_example.cpp, c10_custom_cs_example.cpp, c11_custom_cs_transform_example.cpp.

A custom non-standard example, a custom fusion example, a custom coordinate system example and a custom coordinate system transform example are all in that list. That is a library that expects you to bring your own types, and the examples are arranged to show you how.

The directory layout shows a library with its own documentation and test machinery

The repository layout is the clearest description of how the library is organised, and it is worth reading before you decide anything.

There is doc, which holds the QuickBook documentation sources with embedded examples located in doc/src/examples/. There is example, the standalone examples. There is _extensions_, described as examples and tests for the extensions, and the note says that is the develop branch. There is include, the sourcecode of Boost.Geometry. There is index, examples and tests for the Spatial Index. There is meta, the library metadata. And there is test, the unit tests.

The extensions directory is the one to notice. Boost libraries in this collection often have an extensions mechanism, and the README says plainly that the extensions live on the develop branch. That is a meaningful choice for an adopter, because the develop branch is where work lands and where the newer material is, while master is the stable line.

The spatial index has its own directory and its own examples and tests, which tells you the R-tree index is a first-class part of the library rather than an afterthought, and the topic tags include spatial-index and spatial-analysis, which matches.

Around the source there is the standard Boost packaging furniture. There is a build.jam, a CMakeLists.txt, a sublibs directory, an index.html, a LICENSE_1_0.txt, a CONTRIBUTING.md and a CITATION.cff, the last being the citation metadata format used by journals, and the README even carries a DOI badge pointing at a Journal of Open Source Software entry. A library with a DOI has been through a review, which is a different kind of quality signal from a test count.

The default branch is develop, and the last push to the repository was on 2026-10-12.

Testing is organised around a regression service, not just a CI badge

The test results table in the README is more informative than a row of green badges, because it shows what is being tracked on which branch.

Both develop and master have a CircleCI build badge and a minimal workflow badge, two coverage services with coveralls and codecov, and regression links, three on develop and two on master. The regression links point at regression.boost.io with separate pages for geometry, an index section and an extensions section, and a documentation workflow badge for the docs build.

The regression service is the notable part. Boost runs a shared regression system where every library's test output is compared against known-good results, so a change that alters a numeric result in a geometry algorithm shows up as a diff in a central place rather than as a green build with a quietly different answer. For a library of numerical algorithms, that is the difference between a test suite that catches regressions and one that only catches crashes.

The extensions regression page existing as a separate entry is a consequence of the extensions living on develop. The develop branch therefore has both more material and a separate regression track for it.

The repository also has its own test/ directory for unit tests, index/ for the spatial index tests, and example/ containing the standalone examples which double as documentation. There is a doc/src/examples/ tree as well, which is where the examples embedded in the QuickBook documentation sources live, so the same code is presented both standalone and in context.

For a contributor, the practical takeaway is that the regression results are the acceptance criterion. A pull request that changes an algorithm's output has to update the reference results deliberately, and the diff shows reviewers exactly which numbers moved.

Where Boost.Geometry is the wrong tool

The first wrong-tool case is a project that needs a specific geometric operation done once. Boost.Geometry is a large surface with a concept model attached, and if you want the area of a polygon, the convex hull of a point set, or the distance from a point to a segment, there are smaller libraries that give you that function without the concepts, the header-only include weight, and the C++17 requirement.

The second wrong-tool case is a project on a restricted standard. From Boost 1.95 the library requires C++17. A codebase that has to stay on C++14 because of an embedded toolchain, an old compiler in a build farm, or a certification constraint cannot take a recent Boost.Geometry, and this is not something you can configure around.

The third wrong-tool case is a team that wants a fixed point type. The generic design means every call site has to satisfy the concept, which for a team that just wants to work with one concrete geometry type is overhead rather than benefit. The custom point examples exist because real users do this, but they are not free.

For the alternative approach, the difference in approach is between a generic concept library and a concrete one. A concrete library gives you a Point class with a fixed representation and a set of free functions, and it will be smaller, easier to read, and possibly faster for your case. A generic library gives you the ability to plug in your own representation, which matters when your points come from a simulation kernel, when you need a point type that supports a different numeric model, or when the same algorithm has to run over several types.

There is also the option of a different generic library. The difference in approach there tends to be in the design of the concept layer itself, in whether the library models the geometries as classes with methods or as free functions over primitives, and in how much of the spatial index and overlay functionality is included. Boost.Geometry's breadth is the point: the overlay and transformation examples, the spatial index, and the coordinate-system and fusion support in one place is not something a small library attempts.

The BSL licence, a develop branch, and no tagged releases of its own

The licence is the Boost Software Licence 1.0, and the repository carries LICENSE_1_0.txt. That is the permissive licence Boost uses for its own libraries, and it is what the licence badge points at.

Because Boost.Geometry is part of the Boost collection, its release cycle is Boost's release cycle rather than its own. The repository has no GitHub releases, which is consistent with that: the releases are the Boost release tarballs, and the version of the library you get is the version of Boost you get. The recent-release list for the repository itself is empty for that reason.

That has a practical consequence. You adopt Boost.Geometry by choosing a Boost release, not by pinning a Boost.Geometry version. If you want a specific Boost.Geometry revision, you are working with a Boost superproject checkout and a specific branch of this library inside it, which is a different kind of dependency management from taking a versioned package.

The develop branch is where work lands, and the README's directory note says the extensions are on develop. So the material you want is not necessarily on the line you would get from a release tarball, and the two are tested separately, with their own regression pages.

The last push to the repository was on 2026-10-12, so the tree is being worked on. The maintenance question for an adopter is less about whether the library is abandoned and more about which branch you track and how you handle the C++17 transition, and the mailing list, the wiki and the Gitter chat linked from the README are where those conversations happen.

Editorial conclusion

Boost.Geometry suits a C++ developer who needs computational geometry primitives that handle real data and who is willing to follow the concept model rather than call one library's functions. It does not suit a project pinned to C++14 after Boost 1.95, since the library will require C++17. Before adopting, check the standard requirement against your toolchain, and decide early whether you want the extensions on the develop branch or the conservative set on master, because the two differ in what is available.

Frequently asked questions

Official sources

1. boostorg/geometry on GitHub
2. Issues
3. License: BSL-1.0
4. Project website
5. README