Hi,

So for sure we need a few additional concepts, i.e. Vector, Matrix, Quaternion.

So then quaternion_type<point> and matrix_type<point>? Would this always return square matrix?

I don't see why we should provide concepts for quaternions and rotation matrices right now. Tell me if I misunderstood but I thought the point of the conversation has basically been to say that rotations and translations are just yet another kind of transform strategies. So I thought the plan was to develop new strategy classed to be passed to transform(), implemented in terms of whatever mathematical tool you want to use. "quaternion_rotation", "euler_rotation", "matrix_rotation" would be the names of such strategies. Am I misunderstanding?

we could just put other concepts aside and implement some nice transformation strategies for bg::transform().

If by this you mean what I'm describing above then yes, that would be my approach.

Btw, should the strategy always have input geometries as template parameters? If not, calling bg::transform() could be simplified, e.g.:

I did some work recently on the distance strategies to have them take the input geometries template parameters at function level (in their apply()) rather than class level. Not committed yet, I have to find the time for that. But I guess the same idea would apply for other strategies. Basically we need to free them from their class-level geometry template parameters in order to make then more flexible and easy to use.

bg::transform(poly1, poly2, bg::strategy::make_translation(v_or_p));

Yep, that's exactly the goal of my change (for distance strategies - did nothing on transform strategies so far - the distance strategy change was already a huge work involving hours of work).

Regards

Bruno