666 lines
24 KiB
Plaintext
666 lines
24 KiB
Plaintext
[/==============================================================================
|
||
Copyright (c) 2007-2012 Barend Gehrels, Amsterdam, the Netherlands.
|
||
Copyright (c) 2008-2012 Bruno Lalande, Paris, France.
|
||
Copyright (c) 2009-2012 Mateusz Loskot, London, UK., London, UK
|
||
|
||
Use, modification and distribution is subject to the Boost Software License,
|
||
Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
|
||
http://www.boost.org/LICENSE_1_0.txt)
|
||
===============================================================================/]
|
||
|
||
[/ note the source code in this QBK is the only not (yet) checked by a compiler]
|
||
|
||
[section:design Design Rationale]
|
||
|
||
Suppose you need a C++ program to calculate the distance between two points.
|
||
You might define a struct:
|
||
|
||
struct mypoint
|
||
{
|
||
double x, y;
|
||
};
|
||
|
||
and a function, containing the algorithm:
|
||
|
||
double distance(mypoint const& a, mypoint const& b)
|
||
{
|
||
double dx = a.x - b.x;
|
||
double dy = a.y - b.y;
|
||
return sqrt(dx * dx + dy * dy);
|
||
}
|
||
|
||
Quite simple, and it is usable, but not generic. For a library it has to be
|
||
designed way further. The design above can only be used for 2D points, for the
|
||
struct [*mypoint] (and no other struct), in a Cartesian coordinate system. A
|
||
generic library should be able to calculate the distance:
|
||
|
||
* for any point class or struct, not on just this [*mypoint] type
|
||
* in more than two dimensions
|
||
* for other coordinate systems, e.g. over the earth or on a sphere
|
||
* between a point and a line or between other geometry combinations
|
||
* in higher precision than ['double]
|
||
* avoiding the square root: often we don't want to do that because it is a relatively expensive
|
||
function, and for comparing distances it is not necessary
|
||
|
||
In this and following sections we will make the design step by step more generic.
|
||
|
||
[heading Using Templates]
|
||
|
||
The distance function can be changed into a template function. This is trivial and allows
|
||
calculating the distance between other point types than just [*mypoint]. We add two template
|
||
parameters, allowing input of two different point types.
|
||
|
||
template <typename P1, typename P2>
|
||
double distance(P1 const& a, P2 const& b)
|
||
{
|
||
double dx = a.x - b.x;
|
||
double dy = a.y - b.y;
|
||
return std::sqrt(dx * dx + dy * dy);
|
||
}
|
||
|
||
This template version is slightly better, but not much.
|
||
|
||
Consider a C++ class where member variables are protected...
|
||
Such a class does not allow to access `x` and `y` members directly. So, this paragraph is short
|
||
and we just move on.
|
||
|
||
[heading Using Traits]
|
||
|
||
We need to take a generic approach and allow any point type as input to the distance function.
|
||
Instead of accessing `x` and `y` members, we will add a few levels of indirection, using a
|
||
traits system. The function then becomes:
|
||
|
||
template <typename P1, typename P2>
|
||
double distance(P1 const& a, P2 const& b)
|
||
{
|
||
double dx = get<0>(a) - get<0>(b);
|
||
double dy = get<1>(a) - get<1>(b);
|
||
return std::sqrt(dx * dx + dy * dy);
|
||
}
|
||
|
||
This adapted distance function uses a generic get function, with dimension as a template parameter,
|
||
to access the coordinates of a point. This get forwards to the traits system, defined as following:
|
||
|
||
namespace traits
|
||
{
|
||
template <typename P, int D>
|
||
struct access {};
|
||
}
|
||
|
||
which is then specialized for our [*mypoint] type, implementing a static method called `get`:
|
||
|
||
namespace traits
|
||
{
|
||
template <>
|
||
struct access<mypoint, 0>
|
||
{
|
||
static double get(mypoint const& p)
|
||
{
|
||
return p.x;
|
||
}
|
||
};
|
||
// same for 1: p.y
|
||
...
|
||
}
|
||
|
||
Calling `traits::access<mypoint, 0>::get(a)` now returns us our `x` coordinate. Nice, isn't it?
|
||
It is too verbose for a function like this, used so often in the library. We can shorten the syntax
|
||
by adding an extra free function:
|
||
|
||
template <int D, typename P>
|
||
inline double get(P const& p)
|
||
{
|
||
return traits::access<P, D>::get(p);
|
||
}
|
||
|
||
This enables us to call `get<0>(a)`, for any point having the traits::access specialization,
|
||
as shown in the distance algorithm at the start of this paragraph. So we wanted to enable classes
|
||
with methods like `x()`, and they are supported as long as there is a specialization of the access
|
||
`struct` with a static `get` function returning `x()` for dimension 0, and similar for 1 and `y()`.
|
||
|
||
[heading Dimension Agnosticism]
|
||
|
||
Now we can calculate the distance between points in 2D, points of any structure or class.
|
||
However, we wanted to have 3D as well. So we have to make it dimension agnostic. This complicates
|
||
our distance function. We can use a `for` loop to walk through dimensions, but for loops have
|
||
another performance than the straightforward coordinate addition which was there originally.
|
||
However, we can make more usage of templates and make the distance algorithm as following,
|
||
more complex but attractive for template fans:
|
||
|
||
template <typename P1, typename P2, int D>
|
||
struct pythagoras
|
||
{
|
||
static double apply(P1 const& a, P2 const& b)
|
||
{
|
||
double d = get<D-1>(a) - get<D-1>(b);
|
||
return d * d + pythagoras<P1, P2, D-1>::apply(a, b);
|
||
}
|
||
};
|
||
|
||
template <typename P1, typename P2 >
|
||
struct pythagoras<P1, P2, 0>
|
||
{
|
||
static double apply(P1 const&, P2 const&)
|
||
{
|
||
return 0;
|
||
}
|
||
};
|
||
|
||
The distance function is calling that `pythagoras` structure, specifying the number of dimensions:
|
||
|
||
template <typename P1, typename P2>
|
||
double distance(P1 const& a, P2 const& b)
|
||
{
|
||
BOOST_STATIC_ASSERT(( dimension<P1>::value == dimension<P2>::value ));
|
||
|
||
return sqrt(pythagoras<P1, P2, dimension<P1>::value>::apply(a, b));
|
||
}
|
||
|
||
The dimension which is referred to is defined using another traits class:
|
||
|
||
``
|
||
namespace traits
|
||
{
|
||
template <typename P>
|
||
struct dimension {};
|
||
}
|
||
``
|
||
|
||
which has to be specialized again for the `struct mypoint`.
|
||
|
||
Because it only has to publish a value, we conveniently derive it from the
|
||
__boost_mpl__ `class boost::mpl::int_`:
|
||
|
||
``
|
||
namespace traits
|
||
{
|
||
template <>
|
||
struct dimension<mypoint> : boost::mpl::int_<2>
|
||
{};
|
||
}
|
||
``
|
||
|
||
Like the free get function, the library also contains a dimension meta-function.
|
||
|
||
template <typename P>
|
||
struct dimension : traits::dimension<P>
|
||
{};
|
||
|
||
Below is explained why the extra declaration is useful. Now we have agnosticism in the number of
|
||
dimensions. Our more generic distance function now accepts points of three or more dimensions.
|
||
The compile-time assertion will prevent point a having two dimension and point b having
|
||
three dimensions.
|
||
|
||
[heading Coordinate Type]
|
||
|
||
We assumed double above. What if our points are in integer?
|
||
|
||
We can easily add a traits class, and we will do that. However, the distance between two integer
|
||
coordinates can still be a fractionized value. Besides that, a design goal was to avoid square
|
||
roots. We handle these cases below, in another paragraph. For the moment we keep returning double,
|
||
but we allow integer coordinates for our point types. To define the coordinate type, we add
|
||
another traits class, `coordinate_type`, which should be specialized by the library user:
|
||
|
||
namespace traits
|
||
{
|
||
template <typename P>
|
||
struct coordinate_type{};
|
||
|
||
// specialization for our mypoint
|
||
template <>
|
||
struct coordinate_type<mypoint>
|
||
{
|
||
typedef double type;
|
||
};
|
||
}
|
||
|
||
Like the access function, where we had a free get function, we add a proxy here as well.
|
||
A longer version is presented later on, the short function would look like this:
|
||
|
||
template <typename P>
|
||
struct coordinate_type : traits::coordinate_type<P> {};
|
||
|
||
We now can modify our distance algorithm again. Because it still returns double, we only
|
||
modify the `pythagoras` computation class. It should return the coordinate type of its input.
|
||
But, it has two input, possibly different, point types. They might also differ in their
|
||
coordinate types. Not that that is very likely, but we’re designing a generic library and we
|
||
should handle those strange cases. We have to choose one of the coordinate types and of course
|
||
we select the one with the highest precision. This is not worked out here, it would be too long,
|
||
and it is not related to geometry. We just assume that there is a meta-function `select_most_precise`
|
||
selecting the best type.
|
||
|
||
So our computation class becomes:
|
||
|
||
template <typename P1, typename P2, int D>
|
||
struct pythagoras
|
||
{
|
||
typedef typename select_most_precise
|
||
<
|
||
typename coordinate_type<P1>::type,
|
||
typename coordinate_type<P2>::type
|
||
>::type computation_type;
|
||
|
||
static computation_type apply(P1 const& a, P2 const& b)
|
||
{
|
||
computation_type d = get<D-1>(a) - get<D-1>(b);
|
||
return d * d + pythagoras <P1, P2, D-1> ::apply(a, b);
|
||
}
|
||
};
|
||
|
||
[heading Different Geometries]
|
||
|
||
We have designed a dimension agnostic system supporting any point type of any
|
||
coordinate type. There are still some tweaks but they will be worked out later.
|
||
Now we will see how we calculate the distance between a point and a polygon, or
|
||
between a point and a line-segment. These formulae are more complex, and the
|
||
influence on design is even larger. We don’t want to add a function with another
|
||
name:
|
||
|
||
template <typename P, typename S>
|
||
double distance_point_segment(P const& p, S const& s)
|
||
|
||
We want to be generic, the distance function has to be called from code not
|
||
knowing the type of geometry it handles, so it has to be named distance. We also
|
||
cannot create an overload because that would be ambiguous, having the same
|
||
template signature. There are two solutions:
|
||
|
||
* tag dispatching
|
||
* SFINAE
|
||
|
||
We select tag dispatching because it fits into the traits system. The earlier
|
||
versions (previews) of Boost.Geometry used SFINAE but we found it had several
|
||
drawbacks for such a big design, so the switch to tag dispatching was made.
|
||
|
||
With tag dispatching the distance algorithm inspects the type of geometry of the
|
||
input parameters. The distance function will be changed into this:
|
||
|
||
template <typename G1, typename G2>
|
||
double distance(G1 const& g1, G2 const& g2)
|
||
{
|
||
return dispatch::distance
|
||
<
|
||
typename tag<G1>::type,
|
||
typename tag<G2>::type,
|
||
G1, G2
|
||
>::apply(g1, g2);
|
||
}
|
||
|
||
It is referring to the tag meta-function and forwarding the call to the [*apply] method of
|
||
a ['dispatch::distance] structure. The [*tag] meta-function is another traits class, and should
|
||
be specialized for per point type, both shown here:
|
||
|
||
namespace traits
|
||
{
|
||
template <typename G>
|
||
struct tag {};
|
||
|
||
// specialization
|
||
template <>
|
||
struct tag<mypoint>
|
||
{
|
||
typedef point_tag type;
|
||
};
|
||
}
|
||
|
||
Free meta-function, like coordinate_system and get:
|
||
|
||
template <typename G>
|
||
struct tag : traits::tag<G> {};
|
||
|
||
[*Tags] (`point_tag`, `segment_tag`, etc) are empty structures with the purpose to specialize a
|
||
dispatch struct. The dispatch struct for distance, and its specializations, are all defined
|
||
in a separate namespace and look like the following:
|
||
|
||
namespace dispatch {
|
||
template < typename Tag1, typename Tag2, typename G1, typename G2 >
|
||
struct distance
|
||
{};
|
||
|
||
template <typename P1, typename P2>
|
||
struct distance < point_tag, point_tag, P1, P2 >
|
||
{
|
||
static double apply(P1 const& a, P2 const& b)
|
||
{
|
||
// here we call pythagoras
|
||
// exactly like we did before
|
||
...
|
||
}
|
||
};
|
||
|
||
template <typename P, typename S>
|
||
struct distance
|
||
<
|
||
point_tag, segment_tag, P, S
|
||
>
|
||
{
|
||
static double apply(P const& p, S const& s)
|
||
{
|
||
// here we refer to another function
|
||
// implementing point-segment
|
||
// calculations in 2 or 3
|
||
// dimensions...
|
||
...
|
||
}
|
||
};
|
||
|
||
// here we might have many more
|
||
// specializations,
|
||
// for point-polygon, box-circle, etc.
|
||
|
||
} // namespace
|
||
|
||
So yes, it is possible; the distance algorithm is generic now in the sense that it also
|
||
supports different geometry types. One drawback: we have to define two dispatch specializations
|
||
for point - segment and for segment - point separately. That will also be solved, in the paragraph
|
||
reversibility below. The example below shows where we are now: different point types,
|
||
geometry types, dimensions.
|
||
|
||
point a(1,1);
|
||
point b(2,2);
|
||
std::cout << distance(a,b) << std::endl;
|
||
segment s1(0,0,5,3);
|
||
std::cout << distance(a, s1) << std::endl;
|
||
rgb red(255, 0, 0);
|
||
rbc orange(255, 128, 0);
|
||
std::cout << "color distance: " << distance(red, orange) << std::endl;
|
||
|
||
[heading Kernel Revisited]
|
||
|
||
We described above that we had a traits class `coordinate_type`, defined in namespace traits,
|
||
and defined a separate `coordinate_type` class as well. This was actually not really necessary
|
||
before, because the only difference was the namespace clause. But now that we have another
|
||
geometry type, a segment in this case, it is essential. We can call the `coordinate_type`
|
||
meta-function for any geometry type, point, segment, polygon, etc, implemented again by tag dispatching:
|
||
|
||
template <typename G>
|
||
struct coordinate_type
|
||
{
|
||
typedef typename dispatch::coordinate_type
|
||
<
|
||
typename tag<G>::type, G
|
||
>::type type;
|
||
};
|
||
|
||
Inside the dispatch namespace this meta-function is implemented twice: a generic version and
|
||
one specialization for points. The specialization for points calls the traits class.
|
||
The generic version calls the point specialization, as a sort of recursive meta-function definition:
|
||
|
||
namespace dispatch
|
||
{
|
||
|
||
// Version for any geometry:
|
||
template <typename GeometryTag, typename G>
|
||
struct coordinate_type
|
||
{
|
||
typedef typename point_type
|
||
<
|
||
GeometryTag, G
|
||
>::type point_type;
|
||
|
||
// Call specialization on point-tag
|
||
typedef typename coordinate_type < point_tag, point_type >::type type;
|
||
};
|
||
|
||
// Specialization for point-type:
|
||
template <typename P>
|
||
struct coordinate_type<point_tag, P>
|
||
{
|
||
typedef typename
|
||
traits::coordinate_type<P>::type
|
||
type;
|
||
};
|
||
}
|
||
|
||
So it calls another meta-function point_type. This is not elaborated in here but realize that it
|
||
is available for all geometry types, and typedefs the point type which makes up the geometry,
|
||
calling it type.
|
||
|
||
The same applies for the meta-function dimension and for the upcoming meta-function coordinate system.
|
||
|
||
[heading Coordinate System]
|
||
|
||
Until here we assumed a Cartesian system. But we know that the Earth is not flat.
|
||
Calculating a distance between two GPS-points with the system above would result in nonsense.
|
||
So we again extend our design. We define for each point type a coordinate system type
|
||
using the traits system again. Then we make the calculation dependant on that coordinate system.
|
||
|
||
Coordinate system is similar to coordinate type, a meta-function, calling a dispatch function
|
||
to have it for any geometry-type, forwarding to its point specialization, and finally calling
|
||
a traits class, defining a typedef type with a coordinate system. We don’t show that all here again.
|
||
We only show the definition of a few coordinate systems:
|
||
|
||
struct cartesian {};
|
||
|
||
template<typename DegreeOrRadian>
|
||
struct geographic
|
||
{
|
||
typedef DegreeOrRadian units;
|
||
};
|
||
|
||
So Cartesian is simple, for geographic we can also select if its coordinates are stored in degrees
|
||
or in radians.
|
||
|
||
The distance function will now change: it will select the computation method for the corresponding
|
||
coordinate system and then call the dispatch struct for distance. We call the computation method
|
||
specialized for coordinate systems a strategy. So the new version of the distance function is:
|
||
|
||
template <typename G1, typename G2>
|
||
double distance(G1 const& g1, G2 const& g2)
|
||
{
|
||
typedef typename strategy_distance
|
||
<
|
||
typename coordinate_system<G1>::type,
|
||
typename coordinate_system<G2>::type,
|
||
typename point_type<G1>::type,
|
||
typename point_type<G2>::type,
|
||
dimension<G1>::value
|
||
>::type strategy;
|
||
|
||
return dispatch::distance
|
||
<
|
||
typename tag<G1>::type,
|
||
typename tag<G2>::type,
|
||
G1, G2, strategy
|
||
>::apply(g1, g2, strategy());
|
||
}
|
||
|
||
The strategy_distance mentioned here is a struct with specializations for different coordinate
|
||
systems.
|
||
|
||
template <typename T1, typename T2, typename P1, typename P2, int D>
|
||
struct strategy_distance
|
||
{
|
||
typedef void type;
|
||
};
|
||
|
||
template <typename P1, typename P2, int D>
|
||
struct strategy_distance<cartesian, cartesian, P1, P2, D>
|
||
{
|
||
typedef pythagoras<P1, P2, D> type;
|
||
};
|
||
|
||
So, here is our `pythagoras` again, now defined as a strategy. The distance dispatch function just
|
||
calls its apply method.
|
||
|
||
So this is an important step: for spherical or geographical coordinate systems, another
|
||
strategy (computation method) can be implemented. For spherical coordinate systems
|
||
have the haversine formula. So the dispatching traits struct is specialized like this
|
||
|
||
template <typename P1, typename P2, int D = 2>
|
||
struct strategy_distance<spherical, spherical, P1, P2, D>
|
||
{
|
||
typedef haversine<P1, P2> type;
|
||
};
|
||
|
||
// struct haversine with apply function
|
||
// is omitted here
|
||
|
||
For geography, we have some alternatives for distance calculation. There is the Andoyer method,
|
||
fast and precise, and there is the Vincenty method, slower and more precise, and there are some
|
||
less precise approaches as well.
|
||
|
||
Per coordinate system, one strategy is defined as the default strategy. To be able to use
|
||
another strategy as well, we modify our design again and add an overload for the distance
|
||
algorithm, taking a strategy object as a third parameter.
|
||
|
||
This new overload distance function also has the advantage that the strategy can be constructed
|
||
outside the distance function. Because it was constructed inside above, it could not have
|
||
construction parameters. But for Andoyer or Vincenty, or the haversine formula, it certainly
|
||
makes sense to have a constructor taking the radius of the earth as a parameter.
|
||
|
||
So, the distance overloaded function is:
|
||
|
||
template <typename G1, typename G2, typename S>
|
||
double distance(G1 const& g1, G2 const& g2, S const& strategy)
|
||
{
|
||
return dispatch::distance
|
||
<
|
||
typename tag<G1>::type,
|
||
typename tag<G2>::type,
|
||
G1, G2, S
|
||
>::apply(g1, g2, strategy);
|
||
}
|
||
|
||
The strategy has to have a method apply taking two points as arguments (for points). It is not
|
||
required that it is a static method. A strategy might define a constructor, where a configuration
|
||
value is passed and stored as a member variable. In those cases a static method would be
|
||
inconvenient. It can be implemented as a normal method (with the const qualifier).
|
||
|
||
We do not list all implementations here, Vincenty would cover half a page of mathematics,
|
||
but you will understand the idea. We can call distance like this:
|
||
|
||
distance(c1, c2)
|
||
|
||
where `c1` and `c2` are Cartesian points, or like this:
|
||
|
||
distance(g1, g2)
|
||
|
||
where `g1` and `g2` are Geographic points, calling the default strategy for Geographic
|
||
points (e.g. Andoyer), and like this:
|
||
|
||
distance(g1, g2, vincenty<G1, G2>(6275))
|
||
|
||
where a strategy is specified explicitly and constructed with a radius.
|
||
|
||
[/ 'TODO: What to do with this section? We have concepts already --mloskot]
|
||
[heading Point Concept]
|
||
The five traits classes mentioned in the previous sections form together the
|
||
Point Concept. Any point type for which specializations are implemented in
|
||
the traits namespace should be accepted as a valid type. So the Point Concept
|
||
consists of:
|
||
|
||
* a specialization for `traits::tag`
|
||
* a specialization for `traits::coordinate_system`
|
||
* a specialization for `traits::coordinate_type`
|
||
* a specialization for `traits::dimension`
|
||
* a specialization for `traits::access`
|
||
|
||
The last one is a class, containing the method get and the (optional) method
|
||
set, the first four are metafunctions, either defining type or declaring a
|
||
value (conform MPL conventions).
|
||
|
||
So we now have agnosticism for the number of dimensions, agnosticism for
|
||
coordinate systems; the design can handle any coordinate type, and it can
|
||
handle different geometry types. Furthermore we can specify our own
|
||
strategies, the code will not compile in case of two points with different
|
||
dimensions (because of the assertion), and it will not compile for two points
|
||
with different coordinate systems (because there is no specialization).
|
||
A library can check if a point type fulfills the requirements imposed by the
|
||
concepts. This is handled in the upcoming section Concept Checking.
|
||
|
||
[heading Return Type]
|
||
|
||
We promised that calling `std::sqrt` was not always necessary. So we define a distance result `struct`
|
||
that contains the squared value and is convertible to a double value. This, however, only has to
|
||
be done for `pythagoras`. The spherical distance functions do not take the square root so for them
|
||
it is not necessary to avoid the expensive square root call; they can just return their distance.
|
||
|
||
So the distance result struct is dependant on strategy, therefore made a member type of
|
||
the strategy. The result struct looks like this:
|
||
|
||
template<typename T = double>
|
||
struct cartesian_distance
|
||
{
|
||
T sq;
|
||
explicit cartesian_distance(T const& v) : sq (v) {}
|
||
|
||
inline operator T() const
|
||
{
|
||
return std::sqrt(sq);
|
||
}
|
||
};
|
||
|
||
It also has operators defined to compare itself to other results without taking the square root.
|
||
|
||
Each strategy should define its return type, within the strategy class, for example:
|
||
|
||
typedef cartesian_distance<T> return_type;
|
||
|
||
or:
|
||
|
||
typedef double return_type;
|
||
|
||
for cartesian (pythagoras) and spherical, respectively.
|
||
|
||
Again our distance function will be modified, as expected, to reflect the new return type.
|
||
For the overload with a strategy it is not complex:
|
||
|
||
template < typename G1, typename G2, typename Strategy >
|
||
typename Strategy::return_type distance( G1 const& G1 , G2 const& G2 , S const& strategy)
|
||
|
||
But for the one without strategy we have to select strategy, coordinate type, etc.
|
||
It would be spacious to do it in one line so we add a separate meta-function:
|
||
|
||
template <typename G1, typename G2 = G1>
|
||
struct distance_result
|
||
{
|
||
typedef typename point_type<G1>::type P1;
|
||
typedef typename point_type<G2>::type P2;
|
||
typedef typename strategy_distance
|
||
<
|
||
typename cs_tag<P1>::type,
|
||
typename cs_tag<P2>::type,
|
||
P1, P2
|
||
>::type S;
|
||
|
||
typedef typename S::return_type type;
|
||
};
|
||
|
||
and modify our distance function:
|
||
|
||
template <typename G1, typename G2>
|
||
inline typename distance_result<G1, G2>::type distance(G1 const& g1, G2 const& g2)
|
||
{
|
||
// ...
|
||
}
|
||
|
||
Of course also the apply functions in the dispatch specializations will return a result like this.
|
||
They have a strategy as a template parameter everywhere, making the less verbose version possible.
|
||
|
||
[heading Axis Order]
|
||
|
||
This is an important note for users who develop GIS applications, require compliance with OGC
|
||
standards or use variety of coordinate reference systems (CRS).
|
||
|
||
Boost.Geometry convention is that coordinate values of 2D tuple is always given according to
|
||
mathematical axis order: X,Y. Considering GIS applications, that always means easting,northing or,
|
||
in terms of geographic coordinate system: longitude,latitude.
|
||
Boost.Geometry does not allow or respect coordinate values listed in the axis order as
|
||
specified by coordinate reference system (CRS).
|
||
|
||
In practice, users may easily adapt point types with alternate axis ordering and
|
||
specify coordinate access in order as expected by Boost.Geometry.
|
||
|
||
[heading Summary]
|
||
|
||
In this design rationale, __boost_geometry__ is step by step designed using tag dispatching,
|
||
concepts, traits, and metaprogramming. We used the well-known distance function
|
||
to show the design.
|
||
|
||
__boost_geometry__ is designed like described here, with
|
||
some more techniques as automatically reversing template arguments, tag casting,
|
||
and reusing implementation classes or dispatch classes as policies in other
|
||
dispatch classes.
|
||
|
||
[endsect] [/ end of section Design Rationale]
|