Hi, We've talked about representing positions in space but the other thing I was thinking about when talking about spatial data structures was rotations. Rotations are representable by different kinds of structures (Euler angles, matrices, quaternions...), the choice of which strongly varies with their usage, the needs in performance, the degree of security needed (about gimbal lock and stuff like that), the underlying hardware, etc... The same principle as for points (structure / algorithms separation) cannot apply here since the algorithm needed to do a specific computation is completely different from one type to another. But it would be good to have a concept specifying the interface that a structure must provide to be considered as a "rotation" (rotate() functions, interpolations, point transformations (our Point concept, precisely), conversions from one structure type to another, etc...), and implementing this concept for the most known rotation types (at least the 3 mentioned above). This way : - we have a basic set of rotation data structures to play with - developers of libraries that manipulate rotations only have to focus on this concept Structurally, we already have a quaternion in Boost.Math as well as the uBlas library for matrices. We only need some algorithms above them to make them speak a more "rotational" and common language. Bruno