I have been looking at the advance version of [boost][geometry]. I think it is very useful and very well worked out. I have a question. Does [geometry] support the idea of a frame of reference ? I believe not, but it may be that I have missed some way of achieving this. By reference frame I mean that some points are not directly comparable if they are in different frames of reference. This is distinct from different coordinate systems (I think). For example we could have two geographic coordinate systems, one referring to lat./long. on earth and another to Mars. the points on these two reference frames should not be comparable and should give a compile error. Can this be done in [geometry] ? More interestingly we could use two distinct reference frames for convenience, even though there is a known relation between them. It would be nice if point conversions between the two frames could be carried out (possibly implicitly). For example, I would like to do something like this: ShiftAndRotateTransform<EgocentricFrame, WorldFrame> EgoFrame_WorldFrame_Transform(10, 20, 90); //Shift by [10,20] and rotate 90deg. WorldFrame Test() { WorldFrame p1 = EgoFrame(0,0); EgocentricFrame p2 = WorldFrame(p1); return p2; //IMPORTANT - p2 is implicitly transformed to WorldFrame when returned from Test function. } I have managed to implement a very simple scheme which allows this to compile and work successfully, but I am not completely satisfied with my homebrew scheme. In particular, I am forced to declare the WorldFrame and EgoFrame classes and provide all the constructors for them. It is necessary to explicitly provide constructors for all the reference frames which can be converted - implying that this is known at the time the class is written. It is more flexible to use overloaded functions, because these can be added as required e.g. //The second argument is the output point which is modified. ChangeReferenceFrame(WorldFrame &p1, EgocentricFrame &p2); ChangeReferenceFrame(EgocentricFrame &p1, WorldFrame &p2); ChangeReferenceFrame(EgocentricFrame &p1, SomeNewFrameType &p2); However the syntactic convenience and possibility of implicit conversion is lost. I wonder if some sleight of template magic could allow the extensibility of the second approach with the usability of the first. The starting point would be to allow a class representing the transform between the two frames of reference to be declared. This should attempt to define as much of the machinery as possible. It seems to me that these facilities have no impact on the existing design of [geometry], but concern an extension to allow reference frames to be defined and related.