Re: [boost] [geometry]

Subject: Re: [boost] [geometry]
From: Barend Gehrels (barend_at_[hidden])
Date: 2010-10-10 16:44:14

  hi Paul,

> I have been looking at the advance version of [boost][geometry].  I think it
> is very useful and very well worked out.

Thanks.

> 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).

It is indeed not supported as a distinct feature, but in my opinion it 
is comparable to a coordinate system, the coordinate system concept 
covers (in most cases) these reference frames.

> 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]
> ?

Nice example and yes, these reference frames (so coordinate systems in 
our terms) should not be comparable and give a compile error.

The thing is that e.g. the distance function checks if the two input 
features (e.g. points) have the same coordinate system and calls the 
corresponding strategy. If they have a different coordinate system, it 
fails (or in some cases there may even be strategies that succeed, by 
first converting one of them to another coordinate system, or converting 
both to a common system).

In this sense it has the properties of the reference system.

This applies for two spherical or ellipsoidal systems, as you describe, 
but also for two different cartesian systems (e.g. two different map 
projections).

> 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 like this use case, and it might be implemented somehow. It more or 
less fits into the design. Suppose you will calculate the distance 
between two points of these two frames, a strategy can registered for 
this combination and can call this relation before calculating the 
distance.

> 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.

Within the Boost.Geometry world, the transform function should do this. 
This function, boost::geometry::transform, transforms a geometry (point, 
polygon, etc) to another one, the other one being in another coordinate 
system, or in the same coordinate system but with another type (e.g. 
float to double). Internally, a strategy defining how to go from one to 
another system should be implemented for those systems.

Boost.Geometry is built using tag dispatching; functions are not 
overloaded. When you (in your example) add a tag for reference frames, 
you get rid of the function overloads (convenient, because when using 
templates they will get the same signature). The implementation can be 
in different classes, called by one function. However, implicit 
conversions, if you want them, should be added in another way then.

> 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.

If you have everything outside yes, it might be an extension. However, I 
think you will not profit from it as much - you still get a success when 
calculating the distance between two points in two (externally declared) 
frames. But as said, it is already in the design, at least to some 
extent, if I understand you correctly, and I'm glad with your interest 
and we might think about it and discuss it further.

Regards, Barend