Re: [boost] [geometry]

Subject: Re: [boost] [geometry]
From: Barend Gehrels (barend_at_[hidden])
Date: 2010-10-13 10:57:34

  hi Paul,

>> So you are saying that Mars and Earth would be different coordinate systems,
>> and in the absence of a strategy for transforming between them, the compiler
>> would reject an attempt to pass a point on one coordinate system to a
>> function requiring an argument from the other.

Yes, the compiler would reject it.

>> If a strategy was defined
>> then conversion (implicit or explicit ?) would be possible.  That sounds
>> great.  I suspect this may be a common requirement.

Yes, explicit conversion is possible by calling transform.

>> Is it easy to define a
>> new coordinate system, based on an existing system (and hence automatically
>> aquiring its strategies) ? How do you do it ? I could not find an example in
>> the documentation.

It is easy to define one, but not easy to let everything work with it...

I added two samples, c10_custom_cs_example and 
c11_custom_cs_transform_example to the sandbox,
which:
c10: define a Martian coordinate system and calculate distance between 
two Martian points
c11: define two Cartesian systems and transform a point between those two

I didn't mention earlier, but "coordinate system" is not alone. They are 
also organized into families. Thus two Cartesian systems can get both 
the tag "cartesian". The distance function then automatically works for 
them, taking Pythagoras.

It is also possible to add a new (or user-defined) coordinate system 
tag, of course. That is done in c10 but not in c11.

Furthermore, the distance function between two points in mutually 
different Cartesian coordinate systems compiles. This should actually 
not be the case, and the answer is wrong, so I will solve this. Also, 
the system to register a strategy is slightly different for distance 
(the new system) and transform (the old system), this will be solved as 
well, hopefully very soon. It is just naming style and namespaces.

>
> The idea of implementing a strategy defining how to go from one system to
> the other is just what the doctor ordered !

Good to hear ;-)

>
> How do you register a strategy to transform between coordinate systems in
> [Boost][Geometry] ?

I processed that in the example. But as noted, it will (slightly) change
(so "strategy_transform" will be called 
"strategy::transform::services::default_strategy")

> In order to use different reference frames, I think that the combination of
> the following two steps will be common, and hence should be simple to code:
>
>
>     1. Define new coordinate systems for points on different frames of
>     reference, which use an existing  coordinate system e.g. cartesian
>     2. Register/define the strategy for converting between these coordinate
>     systems.

Exactly.

> The library user can then define constructors as required to enable implit
> conversion between frames of reference.

If he wants, he can do this indeed. Until now I didn't. But yes, it 
should be possible and might be convenient.

This is entirely up to the user, and not part of the library.

> I find implicit conversions very handy.

I think they can be convenient in many cases, as long as the library 
user is aware of it and knows there is a transformations in between. If 
he calls it too much (e.g. in calculations etc), it can affect performance.

> Not an important point but in the documentation I found the use of the word
> 'geometry' confusing.  Geometry appears to refer to a geometric object such
> as a point, box, line segment etc.  At first I expected it to mean something
> like your use of the term 'coordinate system'. i.e. a 'geometry' would be
> something like planar, spherical etc.

I see. Yes, geometry is the name of the library (Boost.Geometry), of the 
namespace, and we have several "geometry types" defined, calling them 
geometry (as parameter) and Geometry (as template parameter)...

It is indeed good to mention something like this in the introduction of 
the documentation. Thanks.

Regards, Barend