Geometry Boost List: [ggl] Physical and logical structure of geometry/strategies

Subject: [ggl] Physical and logical structure of geometry/strategies
From: Mateusz Loskot (mateusz)
Date: 2010-03-13 19:20:57

Hi,

I'm having a little problem with finding pattern of structuring
and naming the algorithmic strategies.

The directories structure looks:

$ tree -d boost/geometry/strategies/
strategies/
|-- agnostic
|-- cartesian
|-- concepts
|-- spherical
`-- transform

Inside, we have a few namespaces defined:

boost::geometry::strategy
boost::geometry::strategy::area
boost::geometry::strategy::buffer
boost::geometry::strategy::centroid_
boost::geometry::strategy::compare
boost::geometry::strategy::convex_hull
boost::geometry::strategy::distance
boost::geometry::strategy::intersection
boost::geometry::strategy::side
boost::geometry::strategy::simplify
boost::geometry::strategy::transform
boost::geometry::strategy::within

(BTW, why centroid_ has underscore suffix?)

Now, for example, taking definitions for area, we have:

1) concept for area strategy

boost::geometry::concept::AreaStrategy

2) trait that matching strategy with coordinate system

boost::geometry::strategy_area

3) metafunction used by the former to define numeric type of area

boost::geometry::area_result

4) concrete strategies

boost::geometry::strategy::area::by_triangles
boost::geometry::strategy::area::huiller

The physical structure of files is clear to me, but I have
a few questions to arrangement of namespaces and definitions:

1) Given the fact we have number of strategy-specific namespaces,
why the result metafunction doesn't sit in there?
For example: boost::geometry::area::result

2) Does the "strategy_" prefix usually denote strategy trait,
by convention of "strategy_<STRATEGY NAME>"?
If it does, why not boost::geometry::strategy::traits::area ?

3) I have an impression that the current logical structure
is to reserve namespace of boost::geometry::strategy::area
for concrete strategies only, but all tools used to generate
strategies like traits and metafunctions, sit on purpose in
namespace boost::geometry. Am I right?

If strategy_area and result_area can not be moved to dedicated
namespace, perhaps it would be a good idea to unify their names,
for example:

area_strategy
area_result

I have an impression of a bit of mess around strategies what makes
it difficult to track and understand. I think it could be better this
part is more modularized.

Perhaps the questions above are irrelevant and I'm confusing the idea,
So, I'd be thankful for explanation.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org