Hi Joachim, This is not yet the review. I'm about halfway and I'm enthousiastic. I've done two small projects inspired on my needs and all I tried is working good, it definitely is a useful library. Questions /remarks though. 1) The set union is modelled as += (doc: "So interval_sets define an operator += that is naturally implemented as set union and an operator -= that is consequently implemented as set difference"), set intersection as &= (according to the doc definition and man_power sample). However, a union is more or less like an OR operation, an intersection like and AND operation, so I would have expected that union would be |=. According to the manual, in another place, that is also supported. Boost.Polygon(BP)/GTL also supports both, for union. Is it intentional that two operators are implemented for the same operation in these two libraries? And if so, why is that not done for the intersection (having synonym *= in BP). Boost.dynamic_bitset also implement all of these: dynamic_bitset& operator&=(const dynamic_bitset& b); Bitwise-AND ... dynamic_bitset& operator|=(const dynamic_bitset& b); Bitwise-OR's... dynamic_bitset& operator^=(const dynamic_bitset& b); Bitwise-XOR's... dynamic_bitset& operator-=(const dynamic_bitset& b); Computes the set difference of this bitset... Boost.Geometry does not (yet) implement operators so we look in a way to conform, if possible, and would like to avoid to introduce synonyms. So I would advocate, for (at least) the four libraries Boost.dynamic_bitset, Boost.Polygon, Boost.Geometry and ITL, the usage of operators conform dynamic bitset, so the following: &= for intersection |= for union ^= for symmetric difference (as is done in both ITL and BP) -= for difference (as is done in both ITL and BP) 2) Same scope, the "boolean" functions "is_disjoint", "contained_in", we in Boost.Geometry have named them (according to ISO/OGC) as "disjoint" and "within". The following functions match: "intersects", "contains" and "touches". And, besides that, ISO/OGC also describe "equals", "overlaps" (where overlaps is roughly intersects, but not completely within, and not touches). So actually we're nearly there, there are just some small differences in names/synonyms. Do you find it a good idea to have / create a common picture of operators and functions and if yes, is it still possible to adapt? Regards, Barend