[Boost-commit] svn:boost r67524 - in trunk/libs/geometry/doc: . concept quickbook reference

Subject: [Boost-commit] svn:boost r67524 - in trunk/libs/geometry/doc: . concept quickbook reference
From: barend.gehrels_at_[hidden]
Date: 2010-12-31 12:54:02

Author: barendgehrels
Date: 2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
New Revision: 67524
URL: http://svn.boost.org/trac/boost/changeset/67524

Log:
Doc update (integration with full reference matrix, created 2 stubfiles for point/box concepts)
Integrated design rationale

Added:
   trunk/libs/geometry/doc/concept/
   trunk/libs/geometry/doc/concept/box.qbk   (contents, props changed)
   trunk/libs/geometry/doc/concept/point.qbk   (contents, props changed)
   trunk/libs/geometry/doc/design_rationale.qbk
      - copied, changed from r67517, /trunk/libs/geometry/doc/quickbook/design_rationale.qbk
Removed:
   trunk/libs/geometry/doc/quickbook/design.qbk
   trunk/libs/geometry/doc/quickbook/design_rationale.qbk
   trunk/libs/geometry/doc/quickbook/extensions.qbk
   trunk/libs/geometry/doc/quickbook/overview.qbk
   trunk/libs/geometry/doc/quickbook/strategies.qbk
   trunk/libs/geometry/doc/reference/concept_point.qbk
Text files modified: 
   trunk/libs/geometry/doc/Jamfile.v2           |     2                                         
   trunk/libs/geometry/doc/design_rationale.qbk |   170 ++++++------------                      
   trunk/libs/geometry/doc/geometry.qbk         |     1                                         
   trunk/libs/geometry/doc/make_qbk.py          |    77 +++-----                                
   trunk/libs/geometry/doc/quickref.xml         |   355 ++++++++++++++++++++++++++++++++++++--- 
   trunk/libs/geometry/doc/reference.qbk        |     7                                         
   6 files changed, 412 insertions(+), 200 deletions(-)

Modified: trunk/libs/geometry/doc/Jamfile.v2
==============================================================================
--- trunk/libs/geometry/doc/Jamfile.v2	(original)
+++ trunk/libs/geometry/doc/Jamfile.v2	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -24,8 +24,6 @@
         <xsl:param>toc.max.depth=2
         <xsl:param>generate.section.toc.level=4
         <xsl:param>boost.root=../../../..
-	<xsl:param>navig.graphics.path=../../../../doc/src/images/
-	<xsl:param>callout.graphics.path=../../../../doc/src/images/callouts/
         ;
 
 

Added: trunk/libs/geometry/doc/concept/box.qbk
==============================================================================
--- (empty file)
+++ trunk/libs/geometry/doc/concept/box.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -0,0 +1,7 @@
+[section:concept_box Box]
+
+[heading Description]
+Stub
+
+[endsect]
+

Added: trunk/libs/geometry/doc/concept/point.qbk
==============================================================================
--- (empty file)
+++ trunk/libs/geometry/doc/concept/point.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -0,0 +1,15 @@
+[section:concept_point Point]
+
+[heading Description]
+Stub
+
+[endsect]
+
+[/ if wished to separate them]
+[/ section:concept::ConstPoint concept::ConstPoint]
+
+[/ heading Description]
+
+
+[/ endsect]
+

Copied: trunk/libs/geometry/doc/design_rationale.qbk (from r67517, /trunk/libs/geometry/doc/quickbook/design_rationale.qbk)
==============================================================================
--- /trunk/libs/geometry/doc/quickbook/design_rationale.qbk	(original)
+++ trunk/libs/geometry/doc/design_rationale.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -28,23 +28,23 @@
     }
 
 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),
+The design above can only be used for 2D points, for the struct [*mypoint] (and no other struct),
 in a __wiki_cs_cartesian__. A generic library should be able to calculate the distance:
 
-* for any point class or struct, not on just this mypoint type
+* 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
+* 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.
 
-[section:templates Using Templates]
+[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
+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>
@@ -61,9 +61,7 @@
 Such a class does not allow to access `x` and `y` members directly. So, this paragraph is short
 and we just move on.
 
-[endsect] [/ end of section Templates]
-
-[section:traits Using Traits]
+[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
@@ -86,7 +84,7 @@
         struct access {};
     }
 
-which is then specialized for our mypoint type, implementing a static method called `get`:
+which is then specialized for our [*mypoint] type, implementing a static method called `get`:
 
     namespace traits
     {
@@ -133,9 +131,7 @@
 This alternative gives in the end the same functionality, either using an `if` statement (wihch
 may be slower), or adding another level of indirection.
 
-[endsect] [/ end of section Traits]
-
-[section:dimension Dimension Agnosticism]
+[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
@@ -163,7 +159,7 @@
         }
     };
 
-The distance function is calling that pythagoras structure, specifying the number of dimensions:
+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)
@@ -175,23 +171,26 @@
 
 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>
+    struct dimension<mypoint> : boost::mpl::int_<2>
     {};
 }
+``
 
 Like the free get function, the library also contains a dimension meta-function.
 
@@ -204,9 +203,7 @@
 The compile-time assertion will prevent point a having two dimension and point b having
 three dimensions.
 
-[endsect] [/ end of section Dimension]
-
-[section:coordinate Coordinate Type]
+[heading Coordinate Type]
 
 We assumed double above. What if our points are in integer?
 
@@ -236,7 +233,7 @@
     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.
+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
@@ -262,9 +259,7 @@
         }
     };
 
-[endsect] [/ end of section Coordinate Type]
-
-[section:geometries Different Geometries]
+[heading Different Geometries]
 
 We’ve 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
@@ -279,13 +274,14 @@
 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:
 
-[/TODO: link --mloskot]
 * tag dispatching
-* __wiki_sfinae__
+* SFINAE
 
-We select tag dispatching because it fits into the traits system, and also because __wiki_sfinae__
-has several drawbacks, listed in another paragraph. With tag dispatching the distance algorithm
-inspects the type of geometry of the input parameters. The distance function will be changed
+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>
@@ -299,8 +295,8 @@
             >::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
+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
@@ -321,7 +317,7 @@
     template <typename G>
     struct tag : traits::tag<G> {};
 
-Tags (`point_tag`, `segment_tag`, etc) are empty structures with the purpose to specialize a
+[*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:
 
@@ -378,9 +374,7 @@
     rbc orange(255, 128, 0);
     std::cout << "color distance: " << distance(red, orange) << std::endl;
 
-[endsect] [/ end of section Different Geometries]
-
-[section:kernel Kernel Revisited]
+[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
@@ -433,9 +427,7 @@
 
 The same applies for the meta-function dimension and for the upcoming meta-function coordinate system.
 
-[endsect] [/ end of section Kernel]
-
-[section:cs 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.
@@ -497,7 +489,7 @@
         typedef pythagoras<P1, P2, D> type;
     };
 
-So, here is our Pythagoras again, now defined as a strategy. The distance dispatch function just
+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
@@ -560,17 +552,37 @@
 
 where a strategy is specified explicitly and constructed with a radius.
 
-[endsect] [/ end of section Coordinate System]
+[/ '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 a as 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.
 
-[section Point Concept]
-['TODO: What to do with this section? We have concepts already --mloskot]
-[endsect] [/ end of section ]
-
-[section Return Type]
+[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
+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
@@ -598,7 +610,7 @@
 
     typedef double return_type
 
-for Pythagoras and spherical, respectively.
+for [*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:
@@ -635,16 +647,14 @@
 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.
 
-[endsect] [/ end of section Return Type]
-
-[section Reversibility]
+[heading Reversibility]
 
 Our `dispatch::distance` class was specialized for <`point_tag`, `segment_tag`>.
 Library users can also call the distance function with a segment and a point, in that order.
 Actually, there are many geometry types (polygon, box, linestring), how to implement all those
 without duplicating all tag dispatching functions? The answer is that we automatically
 reverse the arguments, if appropriate. For distance it is appropriate because distance is a
-commutative function. We add a meta-function geometry_id, which has specializations for each
+commutative function. We add a meta-function `geometry_id`, which has specializations for each
 geometry type, just derived from `boost::mpl::int_`, such that it can be ordered. Point is 1,
 segment is e.g. 2.
 
@@ -697,62 +707,4 @@
 Where the `dispatch::distance_reversed` is a specific struct, forwarding its call to
 `dispatch::distance`, reversing all its template arguments and function arguments.
 
-[endsect] [/ end of section Reversibility]
-
-[section Multi]
-['TODO: What to do with this section? --mloskot]
-[endsect] [/ end of section Multi]
-
-[section SFINAE]
-
-[/TODO: explain a bit more and link --mloskot]
-
-Instead of tag dispatching we alternatively could have chosen for __wiki_sfinae__, mentioned above.
-With __wiki_sfinae__ we add optional parameters to the function, which sole use is to make an
-overload invalid for other geometry types than specified. So, for example:
-
-    template <typename P1, typename P2>
-    inline double distance(P1 const& p1, P2 const& p2, 
-                           typename boost::enable_if <is_point<P1> >::type* = 0,
-                           typename boost::enable_if <is_point<P2> >::type* = 0)
-    {
-        return impl::distance::point_to_point(p1, p2);
-    }
-
-There would then be overloads for point-segment, point-polygon, etc. This __wiki_sfinae__:
-
-* gives often compiler troubles and headaches: if a user makes an error somewhere, the compiler
-will not select any of the methods, and/or it will give completely incomprehensible error listings,
-just because of this __wiki_sfinae__. Stated otherwise (pasted from an answer on the list):
-With __wiki_sfinae__ the real error is hidden behind the phrase "Failed to specialize".
-The compiler discards all overloads, because of an error somewhere, and you get this error with 
-clue how to go on. What you get is the error that it is just failing. All overloads are gone,
-the compiler is not wrong, there is an error somewhere, but the only visible error message which
-makes sense for the compiler to give is something like "failed to specialize" or "no matching
-function call". With tag dispatching you get the real error message. That can also be difficult,
-but the message(s), sometimes a whole list, give at least a clue of what's wrong. In this case:
-add the banana-tag or add an implementation for banana. The usage of concepts should reduce the
-length of the list and give a clearer error message.
-
-* So the essence is: compiler errors in code based on tag dispatching are easier to find than
-compiler errors in code based on SFINAE, because the SFINAE-case is based on discarding overloads
-and meaningful error messages are discarded as well
-
-* the combination of __wiki_sfinae__ and the BCCL using boost-concept-requires has been quite difficult, or impossible
-
-* does not support partial specializations because it is a function. The tag-dispatching function
-is of course also not supporting that, but it forwards its call to the dispatch struct where
-partial specializations (and member template functions) are possible. The SFINAE could do that as
-well but then: why not just add one tag more and have tag dispatching instead?
-
-* is a trick to deceive the compiler. "As a language behavior it was designed to avoid programs becoming ill-formed" (http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error),
-while tag dispatching is based on specialization, a core feature of C++
-
-* is more verbose (tag dispatching makes the main free function declarations shorter)
-
-* several Boost reviewers appreciated the tag dispatching approach and prefered them over SFINAE 
-
-[endsect] [/ end of section Multi]
-
-
-[endsect] [/ end of section Design Rationale]
\ No newline at end of file
+[endsect] [/ end of section Design Rationale]

Modified: trunk/libs/geometry/doc/geometry.qbk
==============================================================================
--- trunk/libs/geometry/doc/geometry.qbk	(original)
+++ trunk/libs/geometry/doc/geometry.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -67,5 +67,6 @@
 [include introduction.qbk]
 [include quickstart.qbk]
 
+[include design_rationale.qbk]
 [include matrix.qbk]
 [include reference.qbk]

Modified: trunk/libs/geometry/doc/make_qbk.py
==============================================================================
--- trunk/libs/geometry/doc/make_qbk.py	(original)
+++ trunk/libs/geometry/doc/make_qbk.py	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -10,64 +10,41 @@
 #  http://www.boost.org/LICENSE_1_0.txt)9
 # ============================================================================
 
-# Note, all of this is very experimental
-# BSG, Aug 1, 2010
 
-import os
+import os, sys
 
-# if a%1 == askip_doxygen goto skip_doxygen
 
-os.chdir("doxy");
-os.system("doxygen")
-os.chdir("..")
+cmd="doxygen_xml2qbk  doxy/doxygen_output/xml/%s.xml ../../../../ boost/geometry/geometry.hpp boost/geometry/geometries/geometries.hpp boost/geometry/multi/multi.hpp > reference/%s.qbk"
 
-#skip_doxygen
+def call_doxygen():
+	os.chdir("doxy");
+	os.system("doxygen")
+	os.chdir("..")
 
-cmd="doxygen_xml2qbk  doxy/doxygen_output/xml/%s.xml ../../../../ boost/geometry/geometry.hpp boost/geometry/geometries/geometries.hpp boost/geometry/multi/multi.hpp > reference/%s.qbk"
+def group_to_quickbook(section):
+	os.system(cmd % ("group__" + section, section))
+
+def xml_to_quickbook(xml, section):
+	os.system(cmd % (xml, section))
+
+
+call_doxygen()
+
+algorithms = ["area", "buffer", "centroid", "combine", "convert" 
+	, "convex_hull", "difference", "disjoint", "dissolve", "distance" 
+	, "envelope", "equals", "for_each", "intersection", "intersects" 
+	, "length", "num_geometries", "num_interior_rings", "num_points" 
+	, "overlaps", "perimeter", "reverse", "simplify", "sym_difference" 
+	, "transform", "union", "unique", "within"]
 
-# Algorithms
-os.system(cmd % ("group__area", "area"))
-os.system(cmd % ("group__buffer", "buffer"))
-os.system(cmd % ("group__centroid", "centroid"));
-os.system(cmd % ("group__convex__hull", "convex_hull"))
-os.system(cmd % ("group__dissolve", "dissolve"))
-os.system(cmd % ("group__envelope", "envelope"))
-os.system(cmd % ("group__length", "length"))
-os.system(cmd % ("group__num__geometries", "num_geometries"))
-os.system(cmd % ("group__num__interior__rings", "num_interior_rings"))
-os.system(cmd % ("group__num__points", "num_points"))
-os.system(cmd % ("group__perimeter", "perimeter"))
-os.system(cmd % ("group__reverse", "reverse"))
-os.system(cmd % ("group__simplify", "simplify"))
-os.system(cmd % ("group__unique", "unique"))
-
-# os.system(cmd % ("group__access", "access"))
-os.system(cmd % ("group__combine", "combine"))
-os.system(cmd % ("group__convert", "convert"))
-os.system(cmd % ("group__difference", "difference"))
-os.system(cmd % ("group__disjoint", "disjoint"))
-
-os.system(cmd % ("group__distance", "distance"))
-
-os.system(cmd % ("group__equals", "equals"))
-os.system(cmd % ("group__for__each", "for_each"))
-
-os.system(cmd % ("group__intersection", "intersection"))
-os.system(cmd % ("group__intersects", "intersects"))
-
-os.system(cmd % ("group__overlaps", "overlaps"))
-os.system(cmd % ("group__sym__difference", "sym_difference"))
-os.system(cmd % ("group__transform", "transform"))
-os.system(cmd % ("group__union", "union"))
-
-os.system(cmd % ("group__within", "within"))
-os.system(cmd % ("group__register", "register"))
+for a in algorithms:
+	group_to_quickbook(a)
 
-os.system(cmd % ("classboost_1_1geometry_1_1point", "point"))
-os.system(cmd % ("classboost_1_1geometry_1_1point__xy", "point_xy"))
+group_to_quickbook("register")
 
-os.system(cmd % ("classboost_1_1geometry_1_1concept_1_1_point", "concept_point"))
+xml_to_quickbook("classboost_1_1geometry_1_1point", "point")
+xml_to_quickbook("classboost_1_1geometry_1_1point__xy", "point_xy")
 
-os.system(cmd % ("structboost_1_1geometry_1_1closing__iterator", "closing_iterator"))
+xml_to_quickbook("structboost_1_1geometry_1_1closing__iterator", "closing_iterator")
 
 os.system("bjam") 

Deleted: trunk/libs/geometry/doc/quickbook/design.qbk
==============================================================================
--- trunk/libs/geometry/doc/quickbook/design.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
+++ (empty file)
@@ -1,22 +0,0 @@
-[/==============================================================================
-    Copyright (c) 1995-2009 Barend Gehrels, Geodan, Amsterdam, the Netherlands.
-    Copyright (c) 2008-2009 Bruno Lalande, Paris, France.
-    Copyright (c) 2009 Mateusz Loskot (mateusz_at_[hidden])
-
-    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)
-===============================================================================/]
-
-[section:design Design]
-
-[include design/introduction.qbk]
-[include design/templates.qbk]
-[include design/traits.qbk]
-[include design/dimension.qbk]
-[include design/coordinate_type.qbk]
-[include design/geometry_type.qbk]
-[include design/coordinate_system.qbk]
-[include design/concepts.qbk]
-
-[endsect]

Deleted: trunk/libs/geometry/doc/quickbook/design_rationale.qbk
==============================================================================
--- trunk/libs/geometry/doc/quickbook/design_rationale.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
+++ (empty file)
@@ -1,758 +0,0 @@
-[/==============================================================================
-    Copyright (c) 1995-2010 Barend Gehrels, Geodan, Amsterdam, the Netherlands.
-    Copyright (c) 2008-2010 Bruno Lalande, Paris, France.
-    Copyright (c) 2009-2010 Mateusz Loskot (mateusz_at_[hidden]), 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)
-===============================================================================/]
-
-[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 __wiki_cs_cartesian__. 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.
-
-[section:templates 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.
-
-[endsect] [/ end of section Templates]
-
-[section:traits 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()`.
-
-Alternatively we could implement, in the traits class, the dimension as a template parameter in
-a member template function:
-
-    template <>
-    struct access<mypoint>
-    {
-        template <int D>
-        static double get(mypoint const& p)
-        // either return x/y using an if-clause
-        // or call a detail-struct specialized
-        //   per dimension
-    };
-
-This alternative gives in the end the same functionality, either using an `if` statement (wihch
-may be slower), or adding another level of indirection.
-
-[endsect] [/ end of section Traits]
-
-[section:dimension 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.
-
-[endsect] [/ end of section Dimension]
-
-[section:coordinate 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);
-        }
-    };
-
-[endsect] [/ end of section Coordinate Type]
-
-[section:geometries Different Geometries]
-
-We’ve 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:
-
-[/TODO: link --mloskot]
-* tag dispatching
-* __wiki_sfinae__
-
-We select tag dispatching because it fits into the traits system, and also because __wiki_sfinae__
-has several drawbacks, listed in another paragraph. 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;
-
-[endsect] [/ end of section Different Geometries]
-
-[section:kernel 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.
-
-[endsect] [/ end of section Kernel]
-
-[section:cs 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.
-
-[endsect] [/ end of section Coordinate System]
-
-[section Point Concept]
-['TODO: What to do with this section? We have concepts already --mloskot]
-[endsect] [/ end of section ]
-
-[section 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 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.
-
-[endsect] [/ end of section Return Type]
-
-[section Reversibility]
-
-Our `dispatch::distance` class was specialized for <`point_tag`, `segment_tag`>.
-Library users can also call the distance function with a segment and a point, in that order.
-Actually, there are many geometry types (polygon, box, linestring), how to implement all those
-without duplicating all tag dispatching functions? The answer is that we automatically
-reverse the arguments, if appropriate. For distance it is appropriate because distance is a
-commutative function. We add a meta-function geometry_id, which has specializations for each
-geometry type, just derived from `boost::mpl::int_`, such that it can be ordered. Point is 1,
-segment is e.g. 2.
-
-Then we add a meta-function reverse_dispatch:
-
-    template <typename G1, typename G2>
-    struct reverse_dispatch : detail::reverse_dispatch
-        <
-            geometry_id<G1>::type::value,
-            geometry_id<G2>::type::value
-        >
-    {};
-
-Because of the order in geometry_id, we can arrange (template) parameters in that order,
-in specializations. So the detail structure looks like:
-
-    namespace detail
-    {
-        template <int Id1, int Id2>
-        struct reverse_dispatch : boost::mpl::if_c
-            <
-                (Id1 > Id2),
-                boost::true_type,
-                boost::false_type
-            >
-        {};
-    }
-
-and our distance function will be modified again with some template meta-programming: We get
-
-    return boost::mpl::if_c
-        <
-            boost::geometry::reverse_dispatch <G1, G2>::type::value,
-            dispatch::distance_reversed
-                <
-                    typename tag<G1>::type,
-                    typename tag<G2>::type,
-                    G1, G2,
-                    // strategy
-                >,
-            dispatch::distance
-                <
-                    typename tag<G1>::type,
-                    typename tag<G2>::type,
-                    G1, G2,
-                    // strategy
-            >
-        >::type::apply(g1, g2, s);
-
-Where the `dispatch::distance_reversed` is a specific struct, forwarding its call to
-`dispatch::distance`, reversing all its template arguments and function arguments.
-
-[endsect] [/ end of section Reversibility]
-
-[section Multi]
-['TODO: What to do with this section? --mloskot]
-[endsect] [/ end of section Multi]
-
-[section SFINAE]
-
-[/TODO: explain a bit more and link --mloskot]
-
-Instead of tag dispatching we alternatively could have chosen for __wiki_sfinae__, mentioned above.
-With __wiki_sfinae__ we add optional parameters to the function, which sole use is to make an
-overload invalid for other geometry types than specified. So, for example:
-
-    template <typename P1, typename P2>
-    inline double distance(P1 const& p1, P2 const& p2, 
-                           typename boost::enable_if <is_point<P1> >::type* = 0,
-                           typename boost::enable_if <is_point<P2> >::type* = 0)
-    {
-        return impl::distance::point_to_point(p1, p2);
-    }
-
-There would then be overloads for point-segment, point-polygon, etc. This __wiki_sfinae__:
-
-* gives often compiler troubles and headaches: if a user makes an error somewhere, the compiler
-will not select any of the methods, and/or it will give completely incomprehensible error listings,
-just because of this __wiki_sfinae__. Stated otherwise (pasted from an answer on the list):
-With __wiki_sfinae__ the real error is hidden behind the phrase "Failed to specialize".
-The compiler discards all overloads, because of an error somewhere, and you get this error with 
-clue how to go on. What you get is the error that it is just failing. All overloads are gone,
-the compiler is not wrong, there is an error somewhere, but the only visible error message which
-makes sense for the compiler to give is something like "failed to specialize" or "no matching
-function call". With tag dispatching you get the real error message. That can also be difficult,
-but the message(s), sometimes a whole list, give at least a clue of what's wrong. In this case:
-add the banana-tag or add an implementation for banana. The usage of concepts should reduce the
-length of the list and give a clearer error message.
-
-* So the essence is: compiler errors in code based on tag dispatching are easier to find than
-compiler errors in code based on SFINAE, because the SFINAE-case is based on discarding overloads
-and meaningful error messages are discarded as well
-
-* the combination of __wiki_sfinae__ and the BCCL using boost-concept-requires has been quite difficult, or impossible
-
-* does not support partial specializations because it is a function. The tag-dispatching function
-is of course also not supporting that, but it forwards its call to the dispatch struct where
-partial specializations (and member template functions) are possible. The SFINAE could do that as
-well but then: why not just add one tag more and have tag dispatching instead?
-
-* is a trick to deceive the compiler. "As a language behavior it was designed to avoid programs becoming ill-formed" (http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error),
-while tag dispatching is based on specialization, a core feature of C++
-
-* is more verbose (tag dispatching makes the main free function declarations shorter)
-
-* several Boost reviewers appreciated the tag dispatching approach and prefered them over SFINAE 
-
-[endsect] [/ end of section Multi]
-
-
-[endsect] [/ end of section Design Rationale]
\ No newline at end of file

Deleted: trunk/libs/geometry/doc/quickbook/extensions.qbk
==============================================================================
--- trunk/libs/geometry/doc/quickbook/extensions.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
+++ (empty file)
@@ -1,50 +0,0 @@
-[/==============================================================================
-    Copyright (c) 1995-2010 Barend Gehrels, Geodan, Amsterdam, the Netherlands.
-    Copyright (c) 2008-2010 Bruno Lalande, Paris, France.
-    Copyright (c) 2009-2010 Mateusz Loskot (mateusz_at_[hidden]), 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)
-===============================================================================/]
-
-[section Extensions (?)]
-['TODO: long story about extensions here...]
-
-[section:io I/O]
-['TODO: input/output extensions here...]
-
-[section DSV]
-[endsect] [/ end of DSV]
-
-[section SVG]
-[endsect] [/ end of SVG]
-
-['TODO: end of input/output extensions here...]
-[endsect] [/ end of I/O]
-
-[section:spatialindex Spatial Index]
-['TODO: spatial indexes here...]
-
-[section:rtree R-tree]
-['TODO: r-tree index here...]
-[endsect] [/ end of R-tree]
-
-['TODO: end of spatial indexes here...]
-[endsect] [/ end of Spatial Index]
-
-[section GIS]   
-
-[section:io I/O]
-['TODO: gis specific input/output here...]
-[endsect] [/ end of I/O]
-
-[section Projections]
-['TODO: projections here...]
-[endsect] [/ end of Projections]
-
-['TODO: end of long GIS story here...]
-[endsect] [/ end of GIS]
-
-['TODO: end of long story about extensions here...]
-[endsect] [/ end of section Extensions]

Deleted: trunk/libs/geometry/doc/quickbook/overview.qbk
==============================================================================
--- trunk/libs/geometry/doc/quickbook/overview.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
+++ (empty file)
@@ -1,21 +0,0 @@
-[/==============================================================================
-    Copyright (c) 1995-2010 Barend Gehrels, Geodan, Amsterdam, the Netherlands.
-    Copyright (c) 2008-2010 Bruno Lalande, Paris, France.
-    Copyright (c) 2009-2010 Mateusz Loskot (mateusz_at_[hidden]), 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)
-===============================================================================/]
-
-[section:overview Overview]
-
-[include design_rationale.qbk]
-[include strategy_rationale.qbk]
-[include boolean.qbk]
-
-[section Robustness (?)]
-['TODO: how robust we are here...]
-[endsect]
-
-[endsect] [/ end of section Library Overview]

Deleted: trunk/libs/geometry/doc/quickbook/strategies.qbk
==============================================================================
--- trunk/libs/geometry/doc/quickbook/strategies.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
+++ (empty file)
@@ -1,17 +0,0 @@
-[/==============================================================================
-    Copyright (c) 1995-2010 Barend Gehrels, Geodan, Amsterdam, the Netherlands.
-    Copyright (c) 2008-2010 Bruno Lalande, Paris, France.
-    Copyright (c) 2009-2010 Mateusz Loskot (mateusz_at_[hidden]), 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)
-===============================================================================/]
-
-[section:strategies Strategies (?)]
-
-[heading Headers]
-
-    #include <boost/geometry/strategies/strategies.hpp>
-
-[endsect] [/ end of section Strategies]

Modified: trunk/libs/geometry/doc/quickref.xml
==============================================================================
--- trunk/libs/geometry/doc/quickref.xml	(original)
+++ trunk/libs/geometry/doc/quickref.xml	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -29,40 +29,28 @@
    <entry valign="top">
     <bridgehead renderas="sect3">0-dimensional</bridgehead>
     <simplelist type="vert" columns="1">
-     <member><link linkend="geometry.reference.concept__Point">concept::Point</link></member>
-     <member><link linkend="geometry.reference.concept__ConstPoint">concept::ConstPoint</link></member>
+     <member><link linkend="geometry.reference.concepts.concept_point">Point</link></member>
+     <member><link linkend="geometry.reference.concepts.concept_multi_point">Multi-Point</link></member>
       </simplelist>
     </entry>
     <entry valign="top">
     <bridgehead renderas="sect3">1-dimensional</bridgehead>
     <simplelist type="vert" columns="1">
-     <member><link linkend="geometry.reference.concept__Segment">concept::Segment</link></member>
-     <member><link linkend="geometry.reference.concept__ConstSegment">concept::ConstSegment</link></member>
-     <member><link linkend="geometry.reference.concept__Linestring">concept::Linestring</link></member>
-     <member><link linkend="geometry.reference.concept__ConstLinestring">concept::ConstLinestring</link></member>
+     <member><link linkend="geometry.concept.concept_segment">Segment</link></member>
+     <member><link linkend="geometry.concept.concept_linestring">Linestring</link></member>
+     <member><link linkend="geometry.concept.concept_multi_linestring">Multi-Linestring</link></member>
     </simplelist>
    </entry>
    <entry valign="top">
     <bridgehead renderas="sect3">2-dimensional</bridgehead>
     <simplelist type="vert" columns="1">
-     <member><link linkend="geometry.reference.concept__Box">concept::Box</link></member>
-     <member><link linkend="geometry.reference.concept__ConstBox">concept::ConstBox</link></member>
-     <member><link linkend="geometry.reference.concept__Ring">concept::Ring</link></member>
-     <member><link linkend="geometry.reference.concept__ConstRing">concept::ConstRing</link></member>
-     <member><link linkend="geometry.reference.concept__Polygon">concept::Polygon</link></member>
-     <member><link linkend="geometry.reference.concept__ConstPolygon">concept::ConstPolygon</link></member>
+     <member><link linkend="geometry.reference.concept.conceptbox">Box</link></member>
+     <member><link linkend="geometry.concept.concept_ring">Ring</link></member>
+     <member><link linkend="geometry.concept.concept_polygon">Polygon</link></member>
+     <member><link linkend="geometry.concept.concept_multi_polygon">Mulit-Polygon</link></member>
     </simplelist>
    </entry>
   </row>
-  <row>
-   <entry valign="center" namest="a" nameend="c">
-    <bridgehead renderas="sect3">Functions</bridgehead>
-    <simplelist type="vert" columns="1">
-     <member><link linkend="geometry.reference.concept__check">concept::check</link></member>
-     <member><link linkend="geometry.reference.concept__check_concepts_and_equal_dimensions">concept::check_concepts_and_equal_dimensions</link></member>
-      </simplelist>
-    </entry>
-  </row>
  </tbody>
 </tgroup>
 
@@ -85,8 +73,6 @@
     <simplelist type="vert" columns="1">
      <member><link linkend="geometry.reference.models.point">point</link></member>
      <member><link linkend="geometry.reference.models.point_xy">point_xy</link></member>
-     <member><link linkend="geometry.reference.models.point_2d">point_2d</link></member>
-     <member><link linkend="geometry.reference.models.point_3d">point_3d</link></member>
       </simplelist>
     </entry>
     <entry valign="top">
@@ -95,31 +81,20 @@
      <member><link linkend="geometry.reference.models.segment">segment</link></member>
      <member><link linkend="geometry.reference.models.segment_2d">segment_2d</link></member>
      <member><link linkend="geometry.reference.models.linestring">linestring</link></member>
-     <member><link linkend="geometry.reference.models.linestring_2d">linestring_2d</link></member>
-     <member><link linkend="geometry.reference.models.linestring_3d">linestring_3d</link></member>
     </simplelist>
    </entry>
    <entry valign="top">
     <bridgehead renderas="sect3">2-dimensional</bridgehead>
     <simplelist type="vert" columns="1">
      <member><link linkend="geometry.reference.models.box">box</link></member>
-     <member><link linkend="geometry.reference.models.box_2d">box_2d</link></member>
-     <member><link linkend="geometry.reference.models.box_3d">box_3d</link></member>
      <member><link linkend="geometry.reference.models.box">box</link></member>
      <member><link linkend="geometry.reference.models.linear_ring">linear_ring</link></member>
-     <member><link linkend="geometry.reference.models.ring_2d">ring_2d</link></member>
-     <member><link linkend="geometry.reference.models.ring_3d">ring_3d</link></member>
      <member><link linkend="geometry.reference.models.polygon">polygon</link></member>
-     <member><link linkend="geometry.reference.models.polygon_2d">polygon_2d</link></member>
-     <member><link linkend="geometry.reference.models.polygon_3d">polygon_3d</link></member>
     </simplelist>
    </entry>
   </row>
   <row>
    <entry valign="top" namest="a" nameend="c">
-    <bridgehead renderas="sect3">Functions</bridgehead>
-    <simplelist type="vert" columns="1">
-    </simplelist>
     <bridgehead renderas="sect3">Macros</bridgehead>
     <simplelist type="vert" columns="1">
      <member><link linkend="geometry.reference.models.register.BOOST_GEOMETRY_REGISTER_POINT_2D_5">BOOST_GEOMETRY_REGISTER_POINT_2D</link></member>
@@ -130,7 +105,143 @@
  </tbody>
 </tgroup>
 
+<!-- ###### CORE ############################################################################### -->
+<tgroup cols="2">
+ <colspec colname="a"/>
+ <colspec colname="b"/>
+ <thead>
+  <row>
+   <entry valign="center" namest="a" nameend="b">
+    <bridgehead renderas="sect2">Core</bridgehead>
+   </entry>
+  </row>
+ </thead>
+ <tbody>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Metafunctions</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.cs_tag">cs_tag</link></member>
+     <member><link linkend="boost_geometry.reference.coordinate_type">coordinate_type</link></member>
+     <member><link linkend="boost_geometry.reference.coordinate_system">coordinate_system</link></member>
+     <member><link linkend="boost_geometry.reference.dimension">dimension</link></member>
+     <member><link linkend="boost_geometry.reference.geometry_id">geometry_id</link></member>
+     <member><link linkend="boost_geometry.reference.interior_type">interior_type</link></member>
+     <member><link linkend="boost_geometry.reference.is_linear">is_linear</link></member>
+     <member><link linkend="boost_geometry.reference.is_multi">is_multi</link></member>
+     <member><link linkend="boost_geometry.reference.is_radian">is_radian</link></member>
+     <member><link linkend="boost_geometry.reference.point_order">point_order</link></member>
+     <member><link linkend="boost_geometry.reference.point_type">point_type</link></member>
+     <member><link linkend="boost_geometry.reference.ring_type">ring_type</link></member>
+     <member><link linkend="boost_geometry.reference.replace_point_type">replace_point_type</link></member>
+     <member><link linkend="boost_geometry.reference.reverse_dispatch">reverse_dispatch</link></member>
+     <member><link linkend="boost_geometry.reference.tag">tag</link></member>
+     <member><link linkend="boost_geometry.reference.topological_dimension">topological_dimension</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Access Functions</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.exterior_ring">exterior_ring</link></member>
+     <member><link linkend="boost_geometry.reference.get">get</link></member>
+     <member><link linkend="boost_geometry.reference.get_as_radian">get_as_radian</link></member>
+     <member><link linkend="boost_geometry.reference.interior_rings">interior_rings</link></member>
+     <member><link linkend="boost_geometry.reference.num_interior_rings">num_interior_rings</link></member>
+     <member><link linkend="boost_geometry.reference.num_points">num_points</link></member>
+     <member><link linkend="boost_geometry.reference.set">set</link></member>
+     <member><link linkend="boost_geometry.reference.set_from_radian">set_from_radian</link></member>
+    </simplelist>
+    <bridgehead renderas="sect3">Classes</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.exception">exception</link></member>
+     <member> <link linkend="boost_geometry.reference.centroid_exception">centroid_exception</link></member>
+    </simplelist>
+   </entry>
+  </row>
+ </tbody>
+</tgroup>
+
+<!-- ###### CONSTANTS ########################################################################## -->
+<tgroup cols="2">
+ <colspec colname="a"/>
+ <colspec colname="b"/>
+  <thead>
+  <row>
+   <entry valign="center" namest="a" nameend="b">
+    <bridgehead renderas="sect2">Constants</bridgehead>
+   </entry>
+  </row>
+ </thead>
+ <tbody>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Numeric</bridgehead>
+    <simplelist type="vert" columns="1">
+    <member><link linkend="boost_geometry.reference.max_corner">max_corner</link></member>
+    <member><link linkend="boost_geometry.reference.min_corner">min_corner</link></member>
+    <member><link linkend="boost_geometry.reference.order_selector">order_selector</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Types</bridgehead>
+    <simplelist type="vert" columns="1">
+    <member><link linkend="boost_geometry.reference.degree">degree</link></member>
+    <member><link linkend="boost_geometry.reference.radian">radian</link></member>
+    </simplelist>
+   </entry>
+  </row>
+ </tbody>
+</tgroup>
 
+<!-- ###### COORDINATE SYSTEMS / ITERATORS ##################################################### -->
+<tgroup cols="2">
+ <colspec colname="a"/>
+ <colspec colname="b"/>
+ <colspec colname="c"/>
+  <thead>
+  <row>
+   <entry valign="center" namest="a" nameend="a">
+    <bridgehead renderas="sect2">Coordinate Systems</bridgehead>
+   </entry>
+   <entry valign="center" namest="b" nameend="c">
+    <bridgehead renderas="sect2">Iterators</bridgehead>
+   </entry>
+  </row>
+ </thead>
+ <tbody>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Classes</bridgehead>
+    <simplelist type="vert" columns="1">
+    <member><link linkend="boost_geometry.reference.cs__cartesian">cs::cartesian</link></member>
+    <member><link linkend="boost_geometry.reference.cs__geographic">cs::geographic</link></member>
+    <member><link linkend="boost_geometry.reference.cs__polar">cs::polar</link></member>
+    <member><link linkend="boost_geometry.reference.cs__spherical">cs::spherical</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Metafunctions</bridgehead>
+    <simplelist type="vert" columns="1">
+    <member><link linkend="boost_geometry.reference.range_type">range_type</link></member>
+    </simplelist>
+    <bridgehead renderas="sect3">Classes</bridgehead>
+    <simplelist type="vert" columns="1">
+    <member><link linkend="boost_geometry.reference.circular_iterator">circular_iterator</link></member>
+    <member><link linkend="boost_geometry.reference.ever_circling_iterator">ever_circling_iterator</link></member>
+    <member><link linkend="boost_geometry.reference.one_section_segment_iterator">one_section_segment_iterator</link></member>
+    <member><link linkend="boost_geometry.reference.section_iterator">section_iterator</link></member>
+    <member><link linkend="boost_geometry.reference.segment_iterator">segment_iterator</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Functions</bridgehead>
+    <simplelist type="vert" columns="1">
+    <member><link linkend="boost_geometry.reference.make_segment_iterator">make_segment_iterator</link></member>
+    </simplelist>
+   </entry>
+  </row>
+ </tbody>
+</tgroup>
 
 <!-- ###### ALGORITHMS ######################################################################### -->
 <tgroup cols="3">
@@ -268,5 +379,181 @@
  </tbody>
 </tgroup>
 
+<!-- ###### POLICIES ########################################################################### -->
+<tgroup cols="2">
+ <colspec colname="a"/>
+ <colspec colname="b"/>
+  <thead>
+  <row>
+   <entry valign="center" namest="a" nameend="b">
+    <bridgehead renderas="sect2">Policies</bridgehead>
+   </entry>
+  </row>
+ </thead>
+ <tbody>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Compare</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.equal_to">equal_to</link></member>
+     <member><link linkend="boost_geometry.reference.greater">greater</link></member>
+     <member><link linkend="boost_geometry.reference.less">less</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Relate</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.policies__relate__direction_type">policies::relate::direction_type</link></member>
+     <member><link linkend="boost_geometry.reference.policies__relate__segments_de9im">policies::relate::segments_de9im</link></member>
+     <member><link linkend="boost_geometry.reference.policies__relate__segments_direction">policies::relate::segments_direction</link></member>
+     <member><link linkend="boost_geometry.reference.policies__relate__segments_intersection_points">policies::relate::segments_intersection_points</link></member>
+     <member><link linkend="boost_geometry.reference.policies__relate__segments_tupled">policies::relate::segments_tupled</link></member>
+    </simplelist>
+   </entry>
+  </row>
+ </tbody>
+</tgroup>
+
+
+<!-- ###### STRATEGIES ######################################################################### -->
+<tgroup cols="3">
+ <colspec colname="a"/>
+ <colspec colname="b"/>
+ <colspec colname="c"/>
+  <thead>
+  <row>
+   <entry valign="center" namest="a" nameend="c">
+    <bridgehead renderas="sect2">Strategies</bridgehead>
+   </entry>
+  </row>
+ </thead>
+ <tbody>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Area</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.strategy_area">strategy_area</link></member>
+     <member><link linkend="boost_geometry.reference.area_result">area_result</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__area__by_triangles">strategy::area::by_triangles</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__area__huiller">strategy::area::huiller</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Centroid</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.strategy_centroid">strategy_centroid</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__centroid___bashein_detmer">strategy::centroid_::bashein_detmer</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__centroid___centroid_average">strategy::centroid_::centroid_average</link></member>
+    </simplelist>
+   </entry>
+  </row>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Distance</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.strategy__distance__projected_point">strategy::distance::projected_point</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__distance__pythagoras">strategy::distance::pythagoras</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__distance__cross_track">strategy::distance::cross_track</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__distance__haversine">strategy::distance::haversine</link></member>
+    </simplelist>
+   </entry>
+  </row>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Side</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.strategy__side__course">strategy::side::course</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__side__side_by_triangle">strategy::side::side_by_triangle</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__side__side_by_cross_track">strategy::side::side_by_cross_track</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Simplify</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.strategy__simplify__douglas_peucker">strategy::simplify::douglas_peucker</link></member>
+    </simplelist>
+   </entry>
+  </row>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Transform</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.strategy__transform__inverse_transformer">strategy::inverse_transformer</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__transform__map_transformer">strategy::map_transformer</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__transform__ublas_transformer">strategy::ublas_transformer</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__transform__translate_transformer">strategy::translate_transformer</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__transform__scale_transformer">strategy::scale_transformer</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__transform__rotate_transformer">strategy::rotate_transformer</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Within</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.strategy__within__winding">strategy::winding</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__within__crossings_multiply">strategy::crossings_multiply</link></member>
+     <member><link linkend="boost_geometry.reference.strategy__within__franklin">strategy::franklin</link></member>
+    </simplelist>
+   </entry>
+  </row>
+ </tbody>
+</tgroup>
+
+
+
+<!-- ###### ARITHMETIC ######################################################################### -->
+<tgroup cols="4">
+ <colspec colname="a"/>
+ <colspec colname="b"/>
+ <colspec colname="c"/>
+ <colspec colname="d"/>
+ <thead>
+  <row>
+   <entry valign="center" namest="a" nameend="d">
+    <bridgehead renderas="sect2">Arithmetic</bridgehead>
+   </entry>
+  </row>
+ </thead>
+ <tbody>
+  <row>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Add</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.add_point">add_point</link></member>
+     <member><link linkend="boost_geometry.reference.add_value">add_value</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Subtract</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.subtract_point">subtract_point</link></member>
+     <member><link linkend="boost_geometry.reference.subtract_value">subtract_value</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Multiply</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.multiply_point">multiply_point</link></member>
+     <member><link linkend="boost_geometry.reference.multiply_value">multiply_value</link></member>
+    </simplelist>
+   </entry>
+   <entry valign="top">
+    <bridgehead renderas="sect3">Divide</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.divide_point">divide_point</link></member>
+     <member><link linkend="boost_geometry.reference.divide_value">divide_value</link></member>
+    </simplelist>
+   </entry>
+  </row>
+  <row>
+   <entry valign="center" namest="a" nameend="d">
+    <bridgehead renderas="sect3">Products</bridgehead>
+    <simplelist type="vert" columns="1">
+     <member><link linkend="boost_geometry.reference.cross_product">cross_product</link></member>
+     <member><link linkend="boost_geometry.reference.dot_product">dot_product</link></member>
+    </simplelist>
+   </entry>
+  </row>
+ </tbody>
+</tgroup>
 
 </informaltable>

Modified: trunk/libs/geometry/doc/reference.qbk
==============================================================================
--- trunk/libs/geometry/doc/reference.qbk	(original)
+++ trunk/libs/geometry/doc/reference.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
@@ -108,11 +108,8 @@
 
 
 [section:concepts Concepts]
-
-[section:concept_point point]
-[include reference/concept_point.qbk]
-[endsect]
-
+[include concept/point.qbk]
+[include concept/box.qbk]
 [endsect]
 
 

Deleted: trunk/libs/geometry/doc/reference/concept_point.qbk
==============================================================================
--- trunk/libs/geometry/doc/reference/concept_point.qbk	2010-12-31 12:54:01 EST (Fri, 31 Dec 2010)
+++ (empty file)
@@ -1,38 +0,0 @@
-[/ Generated by doxygen_xml2qbk, don't change, it will be overwritten automatically]
-[/ Generated from doxy/doxygen_output/xml/classboost_1_1geometry_1_1concept_1_1_point.xml]
-[section:concept::Point concept::Point]
-
-[heading Description]
-A legacy point, defining the necessary specializations to fulfil to the concept.
-
-Suppose that the following point is defined:  
-
-It can then be adapted to the concept as following:  
-
-Note that it is done like above to show the system. Users will normally use the registration macro.
-
-A read-only legacy point, using a macro to fulfil to the 
-
-The point looks like the following:
-
-It uses the macro as following:  
-
-[heading Synopsis]
-``template<typename Geometry>
-class concept::Point
-{
-  // ...
-};
-``
-
-[heading Template parameter(s)]
-[table
-[[Parameter] [Description]]
-[[typename Geometry] []]
-]
-
-[heading Header]
-`#include <boost/geometry/geometries/concepts/point_concept.hpp>`
-
-[endsect]
-