[Boost-commit] svn:boost r84557 - in trunk/libs/geometry/doc/index: . rtree

Subject: [Boost-commit] svn:boost r84557 - in trunk/libs/geometry/doc/index: . rtree
From: mateusz_at_[hidden]
Date: 2013-05-30 12:10:19

Author: mloskot
Date: 2013-05-30 12:10:18 EDT (Thu, 30 May 2013)
New Revision: 84557
URL: http://svn.boost.org/trac/boost/changeset/84557

Log:
[geometry] Spell-check spatial index documentation
Text files modified: 
   trunk/libs/geometry/doc/index/introduction.qbk       |     4 ++--                                    
   trunk/libs/geometry/doc/index/rtree/creation.qbk     |     2 +-                                      
   trunk/libs/geometry/doc/index/rtree/experimental.qbk |    14 +++++++-------                          
   trunk/libs/geometry/doc/index/rtree/introduction.qbk |     4 ++--                                    
   trunk/libs/geometry/doc/index/rtree/query.qbk        |     2 +-                                      
   trunk/libs/geometry/doc/index/rtree/quickstart.qbk   |     2 +-                                      
   6 files changed, 14 insertions(+), 14 deletions(-)

Modified: trunk/libs/geometry/doc/index/introduction.qbk
==============================================================================
--- trunk/libs/geometry/doc/index/introduction.qbk	(original)
+++ trunk/libs/geometry/doc/index/introduction.qbk	2013-05-30 12:10:18 EDT (Thu, 30 May 2013)
@@ -26,7 +26,7 @@
 [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 descring the space occupied by
+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
 (geometric objects representations). 
 
@@ -37,7 +37,7 @@
 [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 order to find desired obejcts. On the other hand more complex analysis takes more time. In general faster inserting will result in slower searching
+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.
 Example structures of trees created by use of three different algorithms and operations time are presented below. Data used in benchmark was random,
 non-overlapping boxes.

Modified: trunk/libs/geometry/doc/index/rtree/creation.qbk
==============================================================================
--- trunk/libs/geometry/doc/index/rtree/creation.qbk	(original)
+++ trunk/libs/geometry/doc/index/rtree/creation.qbk	2013-05-30 12:10:18 EDT (Thu, 30 May 2013)
@@ -51,7 +51,7 @@
 
 The predefined `index::indexable<Value>` returns const reference to the `__indexable__` stored in the `__value__`.
 
-[important The translation is done quite frequently inside the continer - each time the rtree needs it. ]
+[important The translation is done quite frequently inside the container - each time the rtree needs it. ]
 
 The predefined `index::equal_to<Value>`:
 

Modified: trunk/libs/geometry/doc/index/rtree/experimental.qbk
==============================================================================
--- trunk/libs/geometry/doc/index/rtree/experimental.qbk	(original)
+++ trunk/libs/geometry/doc/index/rtree/experimental.qbk	2013-05-30 12:10:18 EDT (Thu, 30 May 2013)
@@ -22,13 +22,13 @@
 It is possible to define how distance to the non-point `__value__` should be calculated. To do this one may pass
 a relation object instead of a Point to the nearest predicate, as follows:
 
- /* caluclate distance to the Indexables' nearest points */
+ /* calculate distance to the Indexables' nearest points */
  rtree.query(index::nearest(index::to_nearest(pt), k), std::back_inserter(returned_values)); // same as default
 
- /* caluclate distance to the Indexables' centroid */
+ /* calculate distance to the Indexables' centroid */
  rtree.query(index::nearest(index::to_centroid(pt), k), std::back_inserter(returned_values));
 
- /* caluclate distance to the Indexables' furthest points */
+ /* calculate distance to the Indexables' furthest points */
  rtree.query(index::nearest(index::to_furthest(pt), k), std::back_inserter(returned_values));
 
 [heading Path query]
@@ -68,14 +68,14 @@
  const_query_iterator last = rtree.qend(index::nearest(pt, 5));
  // ...
  for ( ; first != last ; ++first )
-     *first; // do domething with Value
+     *first; // do something with Value
  
  /* C++11 */
  auto first = rtree.qbegin(index::nearest(pt, 5));
  auto last = rtree.qend(index::nearest(pt, 5));
  // ...
  for ( ; first != last ; ++first )
-     *first; // do domething with Value
+     *first; // do something with Value
 
 `qend()` method is overloaded to return a different, lighter type of iterator which may be compared
 with query iterator to check if the querying was finished. But since it has different type than the one returned by
@@ -99,13 +99,13 @@
  end_iterator last = rtree.qend();
  // ...
  for ( ; first != last ; ++first )
-     *first; // do domething with Value
+     *first; // do something with Value
  
  /* C++11 */
  auto first = rtree.qbegin(index::nearest(pt, 5));
  auto last = rtree.qend();
  // ...
  for ( ; first != last ; ++first )
-     *first; // do domething with Value
+     *first; // do something with Value
 
 [endsect] [/ Experimental features /]

Modified: trunk/libs/geometry/doc/index/rtree/introduction.qbk
==============================================================================
--- trunk/libs/geometry/doc/index/rtree/introduction.qbk	(original)
+++ trunk/libs/geometry/doc/index/rtree/introduction.qbk	2013-05-30 12:10:18 EDT (Thu, 30 May 2013)
@@ -16,7 +16,7 @@
 perform a spatial query later. This query may return objects that are inside some area or are close to some point in space
 [footnote Cheung, K.; Fu, A. (1998). /Enhanced Nearest Neighbour Search on the R-tree/].
 
-The __rtree__ structure is presented on the image below. Each __rtree__'s node store a box descring the space occupied by
+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
 (geometric objects representations). 
 
@@ -27,7 +27,7 @@
 [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 order to find desired obejcts. On the other hand more complex analysis takes more time. In general faster inserting will result in slower searching
+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.
 Example structures of trees created by use of three different algorithms and operations time are presented below. Data used in benchmark was random,
 non-overlapping boxes.

Modified: trunk/libs/geometry/doc/index/rtree/query.qbk
==============================================================================
--- trunk/libs/geometry/doc/index/rtree/query.qbk	(original)
+++ trunk/libs/geometry/doc/index/rtree/query.qbk	2013-05-30 12:10:18 EDT (Thu, 30 May 2013)
@@ -162,7 +162,7 @@
 These predicates are connected by logical AND. Passing all predicates together not only makes possible
 to construct advanced queries but is also faster than separate calls because the tree is traversed only once.
 Traversing is continued and `Value`s are returned only if all predicates are met. Predicates are checked
-left-to-right so placing most restictive predicates first should accelerate the search.
+left-to-right so placing most restrictive predicates first should accelerate the search.
 
  rt.query(index::intersects(box1) && !index::within(box2),
           std::back_inserter(result));

Modified: trunk/libs/geometry/doc/index/rtree/quickstart.qbk
==============================================================================
--- trunk/libs/geometry/doc/index/rtree/quickstart.qbk	(original)
+++ trunk/libs/geometry/doc/index/rtree/quickstart.qbk	2013-05-30 12:10:18 EDT (Thu, 30 May 2013)
@@ -18,7 +18,7 @@
 [rtree_quickstart_include]
 
 Typically you'll store e.g. `std::pair<Box, MyGeometryId>` in the __rtree__. `MyGeometryId`
-will be some indentifier of a complex `Geometry` stored in other container, e.g. index type
+will be some identifier of a complex `Geometry` stored in other container, e.g. index type
 of a `Polygon` stored in the vector or an iterator of list of `Ring`s. To keep it simple to
 define `Value` we will use predefined __box__ and unsigned int.