The problem is somewhat the reverse of that actually. People will want to use their point classes that are already model of Boost.Polygon point_concept with the voronoi diagram API and will not be able to because it expects different traits than the point_concept requires.
Yes, so what I meant is that I could change Voronoi builder initialization step code to operate with the Boost.Polygon point_traits, this will look like this: int32 x = point_traits<PointContainer::iterator::value_type>::get(*it, HORIZONTAL); int32 y = point_traits<PointContainer::iterator::value_type>::get(*it, VERTICAL); My point is that if the default point_traits specialization is changed to the one I mentioned in my previous post, this will fix all the issues: 1) The users will be able to use their legacy point classes by specializing point_traits; 2) The users whose point type supports x() and y() access methods won't be required to do anything. The same will apply for the segment class. If we do some additional clean up to the isotropy.hpp header this won't add any heavy dependencies to the current Voronoi code. Please correct me if I am wrong. Thanks, Andrii