Fix mistakes

doc/acknowledgments.qbk

@@ -15,7 +15,7 @@
 We like to thank all the people who helped to develop this library.
 
 First of all we are grateful to Hartmut Kaiser for managing the formal review 
-of this library. Hartmut is an excellent review manager, who intervented when 
+of this library. Hartmut is an excellent review manager, who intervened when 
 necessary and produced the review report quickly.
 
 We thank the 14 reviewers of our library, reviewed from November 5, 2009 to 

doc/compiling.qbk

@@ -20,7 +20,7 @@ library headers in their programs in order to be able to access definitions
 and algorithms provided by the __boost_geometry__ library. No linking against 
 any binaries is required. 
 
-__boost_geometry__ is only dependant on headers-only __boost__ libraries.
+__boost_geometry__ is only dependent on headers-only __boost__ libraries.
 It does not introduce indirect dependencies on any binary libraries.
 
 In order to be able to use __boost_geometry__, the only thing users need to do 
@@ -43,7 +43,7 @@ testing software, to configure, build and execute unit tests and example
 programs. The build configuration is provided as a collection of `Jamfile` 
 files.
 
-For gcc, flag [^-Wno-long-long] can be used to surpress some warnings 
+For gcc, flag [^-Wno-long-long] can be used to suppress some warnings 
 originating from Boost.
 
 [heading Includes]
@@ -58,7 +58,7 @@ recommended to include this file.
 
 Alternatively, it is possible to include __boost_geometry__ header files 
 separately. However, this may be inconvenient as header files might be renamed 
-or moved occasionaly in future.
+or moved occasionally in future.
 
 Another often used header is `geometries.hpp`:
 
@@ -86,7 +86,7 @@ to include.
 
 Users who have their own geometries and want to use algorithms from 
 __boost_geometry__ might include the files containing registration 
-macro's, like:
+macros, like:
 
     #include <boost/geometry/geometries/register/point.hpp>
 
@@ -101,7 +101,7 @@ performance:
   significantly faster code than use of the C++ standard library provided by __msvc__.
 * Turn on compiler optimizations, compile in release mode.
 
-[heading Problems with Intellisense]
+[heading Problems with IntelliSense]
 
 Both versions of __msvc__, 2005 and 2008 (including Express Editions) can hang 
 trying to resolve symbols and give [@http://en.wikipedia.org/wiki/IntelliSense 

doc/concept/box.qbk

@@ -18,7 +18,7 @@
 A box is a geometry with (usually) two or three dimensions, having its axis aligned to the coordinate system. 
 
 The box is not one of the basic types in Boost.Geometry (point, linestring, polygon) but it is a ['helper type]. 
-The main reasons for the box existance are its usefulness for indexing (a spatial index, or splitting a geometry 
+The main reasons for the box existence are its usefulness for indexing (a spatial index, or splitting a geometry 
 into monotonic sections) and it is the output of the [link geometry.reference.algorithms.envelope envelope] algorithm.
 
 Therefore, a box is axis aligned (the envelope is also called aabb, axis aligned bounding box).

doc/concept/point.qbk

@@ -68,7 +68,7 @@ struct access<std::array<T, D>, Index> {
 * [link geometry.reference.adapted.boost_fusion Boost.Fusion]
 * [link geometry.reference.adapted.boost_polygon Boost.Polygon]
 * [link geometry.reference.adapted.boost_tuple Boost.Tuple]
-* other point types, adapted e.g. using one of the [link geometry.reference.adapted.register registration macro's]
+* other point types, adapted e.g. using one of the [link geometry.reference.adapted.register registration macros]
 
 [endsect]
 

doc/design_rationale.qbk

@@ -188,7 +188,7 @@ Like the free get function, the library also contains a dimension meta-function.
 
 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
+The compile-time assertion will prevent point a having two dimensions and point b having
 three dimensions.
 
 [heading Coordinate Type]
@@ -422,7 +422,7 @@ The same applies for the meta-function dimension and for the upcoming meta-funct
 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.
+using the traits system again. Then we make the calculation dependent 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
@@ -575,7 +575,7 @@ that contains the squared value and is convertible to a double value. This, howe
 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
+So the distance result struct is dependent on strategy, therefore made a member type of
 the strategy. The result struct looks like this:
 
     template<typename T = double>

doc/doxy/Doxyfile

@@ -88,7 +88,7 @@ ALIASES                = qbk{1}="\xmlonly <qbk>\1</qbk> \endxmlonly" \
                          param_macro_coorsystem="Coordinate system (e.g. cs::cartesian)" \
                          param_macro_member{1}="Member containing \1 coordinate" \
                          param_macro_getset{2}="Method to \1 the \2 coordinate" \
-                         param_range_point="A range containg points fulfilling range and point concepts" \
+                         param_range_point="A range containing points fulfilling range and point concepts" \
                          param_x="First coordinate (usually x-coordinate)" \
                          param_y="Second coordinate (usually y-coordinate)" \
                          param_z="Third coordinate (usually z-coordinate)" \
@@ -103,7 +103,7 @@ ALIASES                = qbk{1}="\xmlonly <qbk>\1</qbk> \endxmlonly" \
                          details_calc2{1}="The free function \1 calculates the \1 of two geometries" \
                          details_free_function{3}="The free function [^\1] calculates the \2 \3 two geometries" \
                          details_check12{2}="The free function \1 checks if the first geometry \2 the second geometry" \
-                         details_macro{2}="The macro \1 registers a \2 such that it is recognized by Boost.Geometry and that Boost.Geometry functionality can used with the specified type." \
+                         details_macro{2}="The macro \1 registers a \2 such that it is recognized by Boost.Geometry and that Boost.Geometry functionality can be used with the specified type." \
                          details_macro_const="The const version registers only read access to the fields, the point type is therefore read-only." \
                          details_macro_getset="The get/set version registers get and set methods separately and can be used for classes with protected member variables and get/set methods to change coordinates." \
                          details_macro_templated{2}="The type must have one template parameter, which should be a \2 type, and should not be specified. Boost.Geometry takes care of inserting the template parameter. Hence all types of this templated \1 are registered, regardless of their point type." \

doc/example_adapting_a_legacy_geometry_object_model.qbk

@@ -4,15 +4,15 @@ One of the primary benefits of __boost_geometry__, and the reason for its fairly
 
 By defining the relationship between the __boost_geometry__ concepts and an existing, legacy object model, the legacy objects can be used in place of __boost_geometry__'s own geometry classes.
 
-__boost_geometry__ will then happliy read and write directly from and to the legacy object, treating it as a native __boost_geometry__ object.
+__boost_geometry__ will then happily read and write directly from and to the legacy object, treating it as a native __boost_geometry__ object.
 
 This means that one can adapt algorithms and methods from __boost_geometry__ to any existing legacy geometry object model at a very small runtime cost, which is simply not possible with most geometry libraries, where one has to make an intermediate object specific to the geometry library one is using.
 
 The following example will demonstrate the adaption process of a legacy geometry object model for use with __boost_geometry__.
 
 [h2 Adapting a shared geometry legacy object model]
 
-[h3 Example code: object hierarcy]
+[h3 Example code: object hierarchy]
 
     class QPoint 
     {
@@ -42,7 +42,7 @@ The following example will demonstrate the adaption process of a legacy geometry
             std::vector<QRing*> interiors;
     };
 
-The legacy object hierarcy is based on topology (e.g. two QRings might share one QLineString) instead of points directly (i.e. each object does not point directly to it's QPoints), and it also uses pointers for access.
+The legacy object hierarchy is based on topology (e.g. two QRings might share one QLineString) instead of points directly (i.e. each object does not point directly to its QPoints), and it also uses pointers for access.
 
 This is the other common way to approach geometries, to enable e.g. shared boundaries between surfaces. __boost_geometry__'s approach use simple features, and does not have shared geometries.
 
@@ -77,7 +77,7 @@ The [link adaption_of_qring_source_code adaption of the QRing] is mostly equal t
 
 However, the QRing expose pointers-to-QLineStrings, and not QPoints directly, which is [link geometry.reference.concepts.concept_ring required in the Ring concept], so it is not enough to trivially make the std::vector into a __boost_range__. We need to create a Boost.Iterator that expose QPoints, and because we are dealing with a legacy object model, we are not allowed to change the class definition.
 
-The [link adaption_of_qring_iterator_source_code custom iterator that does this] uses Boost.Iterator Facade, and is not very different from the [@http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/iterator_facade.html example provided in Boost.Iterator's own documentation](link), except that our __boost_range__ need to be random access.
+The [link adaption_of_qring_iterator_source_code custom iterator that does this] uses Boost.Iterator Facade, and is not very different from the [@http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/iterator_facade.html example provided in Boost.Iterator's own documentation] (link), except that our __boost_range__ need to be random access.
 
 Now, with the custom iterator made, we can [link adaption_of_qring_range_source_code define the __boost_range__] that traverses through QPoints.
 

doc/geometry.qbk

@@ -111,7 +111,7 @@ Boost.Geometry contains contributions by:
 
 * Akira Takahashi (adaption of Boost.Fusion)
 * Alfredo Correa (adaption of Boost.Array)
-* Andrew Hundt (varray container, aka. static_vector)
+* Andrew Hundt (varray container, aka static_vector)
 * Federico Fern\u00E1ndez (preliminary version of R-tree spatial index)
 * Karsten Ahnert (patch for cross-track distance)
 * Mats Taraldsvik (documentation: adapting a legacy model)

doc/index/introduction.qbk

@@ -12,7 +12,7 @@
 
 The __boost_geometry_index__ is intended to gather data structures called spatial
 indexes which may be used to accelerate searching for objects in space. In general,
-spatial indexes stores geometric objects' representations and allows searching for
+spatial indexes store geometric objects' representations and allow searching for
 objects occupying some space or close to some point in space.
 
 Currently, only one spatial index is implemented - __rtree__.
@@ -26,8 +26,8 @@ perform a spatial query. This query may for example return objects that are insi
 [footnote Cheung, K.; Fu, A. (1998). /Enhanced Nearest Neighbour Search on the R-tree/].
 It's possible to insert new objects or to remove the ones already stored.
 
-The __rtree__ structure is presented on the image below. Each __rtree__'s node store a box describing the space occupied by
-its children nodes. At the bottom of the structure, there are leaf-nodes which contains values
+The __rtree__ structure is presented on the image below. Each __rtree__'s node stores a box describing the space occupied by
+its children nodes. At the bottom of the structure, there are leaf-nodes which contain values
 (geometric objects representations). 
 
 [$img/index/rtree/rstar.png]
@@ -36,11 +36,11 @@ The __rtree__ is a self-balanced data structure. The key part of balancing algor
 [footnote Greene, D. (1989). /An implementation and performance analysis of spatial data access methods/]
 [footnote Beckmann, N.; Kriegel, H. P.; Schneider, R.; Seeger, B. (1990). /The R*-tree: an efficient and robust access method for points and rectangles/].
 Each algorithm produces different splits so the internal structure of a tree may be different for each one of them.
-In general, more complex algorithms analyses elements better and produces less overlapping nodes. In the searching process less nodes must be traversed
+In general, more complex algorithms analyse elements better and produce less overlapping nodes. In the searching process less nodes must be traversed
 in order to find desired objects. On the other hand more complex analysis takes more time. In general faster inserting will result in slower searching
 and vice versa. The performance of the R-tree depends on balancing algorithm, parameters and data inserted into the container.
 
-Additionally there are also algorithms creating R-tree containing some, number of objects. This technique is called bulk loading and is
+Additionally, there are also algorithms creating R-tree containing some number of objects. This technique is called bulk loading and is
 done by use of packing algorithm
 [footnote Leutenegger, Scott T.; Edgington, Jeffrey M.; Lopez, Mario A. (1997). /STR: A Simple and Efficient Algorithm for R-Tree Packing/]
 [footnote Garcia, Yvan J.; Lopez, Mario A.; Leutenegger, Scott T. (1997). /A Greedy Algorithm for Bulk Loading R-trees/].

doc/index/rtree/creation.qbk

@@ -139,7 +139,7 @@ The following code creates an __rtree__ using quadratic balancing algorithm.
  typedef std::pair<Box, int> __value__;
  index::rtree< __value__, index::quadratic<16> > rt;
 
-To insert or remove a `__value__' by method call one may use the following
+To insert or remove a `__value__` by method call one may use the following
 code.
 
  __value__ v = std::make_pair(__box__(...), 0);
@@ -148,7 +148,7 @@ code.
 
  rt.remove(v);
 
-To insert or remove a `__value__' by function call one may use the following
+To insert or remove a `__value__` by function call one may use the following
 code.
 
  __value__ v = std::make_pair(__box__(...), 0);

doc/index/rtree/query.qbk

@@ -10,7 +10,7 @@
 
 [section Queries]
 
-Queries returns `__value__`s which meets some predicates. Currently supported are three types of predicates:
+Queries return `__value__`s which meet some predicates. Currently supported are three types of predicates:
 
 * spatial predicates - spatial conditions that must be met by stored Value and some Geometry,
 * distance predicates - distance conditions that must be met by stored Value and some Geometry,
@@ -25,7 +25,7 @@ For example queries may be used to retrieve Values:
 [h4 Performing a query]
 
 There are various ways to perform a query. They are presented below.
-All of them returns `__value__`s intersecting some region defined as a `__box__`.
+All of them return `__value__`s intersecting some region defined as a `__box__`.
 
 Member function call
 
@@ -59,7 +59,7 @@ Query iterators returned by free functions
 
 [h4 Spatial queries]
 
-Queries using spatial predicates returns `__value__`s which are related somehow to some Geometry - box, polygon, etc.
+Queries using spatial predicates return `__value__`s which are related somehow to some Geometry - box, polygon, etc.
 Names of spatial predicates correspond to names of __boost_geometry__ algorithms (boolean operations).
 Examples of some basic queries may be found in the tables below. The query region and result `Value`s are orange.
 
@@ -101,7 +101,7 @@ All spatial predicates may be negated, e.g.:
 
 [h4 Nearest neighbours queries]
 
-Nearest neighbours queries returns `__value__`s which are closest to some Geometry.
+Nearest neighbours queries return `__value__`s which are closest to some Geometry.
 The examples of k-NN queries are presented below. 5 `__value__`s nearest to the Geometry are orange.
 
 [table

doc/index/rtree/quickstart.qbk

@@ -10,7 +10,7 @@
 
 [section:rtree_quickstart Quick Start]
 
-This Quick Start section shows simple way to creating a typical R-tree and perform
+This Quick Start section shows a simple way to create a typical R-tree and perform
 spatial query.
 
 The code below assumes that following files are included and namespaces used.
@@ -32,7 +32,7 @@ passed as template parameters. Maximum number of elements in nodes is set to 16.
 
 Typically `Value`s will be generated in a loop from e.g. `Polygon`s stored in some other container.
 In this case `Box` objects will probably be created with `geometry::envelope()` function.
-But to keep it simple lets just generate some boxes manually and insert them into the R-tree by
+But to keep it simple let's just generate some boxes manually and insert them into the R-tree by
 using `insert()` method.
 
 [rtree_quickstart_insert]

doc/introduction.qbk

@@ -38,7 +38,7 @@ The library follows existing conventions:
 * conventions from boost
 * conventions from the std library
 * conventions and names from one of the __ogc__ standards on geometry and, more
-    specificly, from the __ogc_sf__
+    specifically, from the __ogc_sf__
 
 The library was first released with Boost 1.47.0 and from that point on it is 
 officially part of the Boost C++ Libraries.

doc/reference.qbk

@@ -63,7 +63,7 @@
 [include reference/geometries/adapted/boost_range/strided.qbk]
 [/ include reference/geometries/adapted/boost_range/uniqued.qbk]
 [endsect]
-[section:register Macro's for adaption]
+[section:register Macros for adaption]
 [include generated/register.qbk]
 [endsect]
 [endsect]

doc/reference/algorithms/append.qbk

@@ -34,15 +34,15 @@
 [[__multi_linestring__][Appends point or range to the end of the
         linestring with the given multi index.
         The multi-linestring is not resized automatically, so ensure
-        that the multi index is smaller than then number of linestring
+        that the multi index is smaller than the number of linestring
         in the multi-linestring.]]
 [[__multi_polygon__][Appends point or range to the end of the polygon
         (without explicitly closing it) with the given multi-index.
         The point or range is appended at the end of the
         exterior ring (the default) or specify a zero-based ring index for
         the interior rings.
         The multi-polygon is not resized automatically, so ensure
-        that the multi index is smaller than then number of polygon
+        that the multi index is smaller than the number of polygon
         in the multi-polygon. The same applies for the interior rings
         of the polygon: the interior rings are not resized
         automatically, so ensure that the zero-based ring index is

doc/reference/algorithms/buffer_with_strategies.qbk

@@ -15,7 +15,7 @@ The 5 strategies give the user control to the generated buffer
 
 * convex corners can be rounded or sharp
 * line-ends can be rounded or flat
-* distance can be symmetric or assymetric, and positive or negative
+* distance can be symmetric or asymmetric, and positive or negative
 * around points the shape can be circular or square
 * the sides can be controlled (currently there is only one option provided)
 

doc/reference/algorithms/expand.qbk

@@ -24,7 +24,7 @@
 [[__box__ / __other__][__nyiversion__]]
 ]
 
-[note To use expand with another geometry type then specified, use expand(make_envelope<box_type>(geometry)]
+[note To use expand with another geometry type than specified, use expand(make_envelope<box_type>(geometry)]
 
 [heading Complexity]
 Linear