Geometry Boost List: [ggl] Custom geometries and GGL header inclusion

Subject: [ggl] Custom geometries and GGL header inclusion
From: Barend Gehrels (Barend.Gehrels)
Date: 2010-03-12 04:55:51

Hi,

Welcome to the list.

> I have some custom geometries, and adapt them to GGL's geometry concept( by
> adding partial specialization to boost::geometry::traits, just like the
> registration macros, except macros can't handle template).
>   
Right.

> Then, I included some access, i/o headers from GGL, wrote a small routine,
> compiled the source(with msvc9), but ended up with dozens errors.
> After including several GGL core headers suggested by error info:
>
> #include <boost/geometry/core/access.hpp>
> #include <boost/geometry/core/coordinate_type.hpp>
> #include <boost/geometry/core/coordinate_system.hpp>
> #include <boost/geometry/core/coordinate_dimension.hpp>
> #include <boost/geometry/core/exterior_ring.hpp>
> #include <boost/geometry/core/interior_rings.hpp>
> #include <boost/geometry/multi/core/tags.hpp>
> #include <boost/geometry/core/point_order.hpp>
>   
Sure, these headers contain namespace traits, so to specialize traits 
classes you have to include these headers indeed. There is currently no 
standard "collection" headerfile to include these. The concept is spread 
over different files indeed (on purpose), and maybe we indeed can 
consider to make such a collecting headerfile for this to make this 
scenario more easy.

Now that I looked again with this point of view, they are indeed missing 
in the register headerfiles and will be added.

> Now, I want my geometries to work with GGL algorithm, so I simply include
> some algorithm header from GGL. After compiling, the compiler generated
> about 20 errors, most of them pointed to the
> boost::geometry::strategy::not_implemented tag. I really have no idea about
> what to include to make the compiler see these "strategies" (there are so
> many headers in geometry/strategies) and make my geometries work with GGL
> algorithms. Finally, I include these"all-in-one" headers suggested by wiki:
>
> #include <boost/geometry/geometries/geometries.hpp>
> #include <boost/geometry/multi/multi.hpp>
>
> and make the routine pass the compiling.
>   
Actually suggested is: <boost/geometry/geometry.hpp> (instead of 
geometries/geometries.hpp)

The strategies are used by several algorithms, some are so basic (e.g. 
side) that they are often used. You might try if

#include <boost/geometry/strategies/strategies.hpp>

Will work for you.

However, if you do it completely manually (e.g. only distance and area), 
you have to include the corresponding algorithms. This is also done in 
all unit tests so it must be possible. Most unit tests include all 
strategies. They are on purpose not included in corresponding 
algorithms. E.g. the area algorithm does not include the area strategy, 
it is decoupled. The strategy is dependant on coordinate system, and the 
algorithm does not know on which coordinate system it operates.

But I understand the problem and we can seen if it can be solved better.

> It confused me a lot, since the way to use header in GGL is kinda different
> from other boost lib. Usually, I want include as small range of headers as
> possible. For example, if a GGL algorithm is needed and should be used with
> custom geometry, I'd want only include one header for custom geometries and
> one for the algorithm. But, actually, you need include lots of core,
> strategy and algorithm headers to make it run.
>   
So, again, the

#include <boost/geometry/strategies/strategies.hpp>

is currently the trick to use, and if you do don't want to use that, you 
have to include the needed strategies manually...

Hope this helps.
Regards, Barend