[boost] [geometry]

Subject: [boost] [geometry]
From: Paul Blampspied (elpidiovaldez5_at_[hidden])
Date: 2010-10-08 13:49:22

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.