Index: doc/doxygen_input/pages/doxygen_a_design_rationale.hpp =================================================================== --- doc/doxygen_input/pages/doxygen_a_design_rationale.hpp (revision 58155) +++ doc/doxygen_input/pages/doxygen_a_design_rationale.hpp (working copy) @@ -685,6 +685,7 @@ typename tag::type, G1, G2, // strategy + > > >::type::apply(g1, g2, s); \endcode Index: doc/doxygen_input/pages/doxygen_c_strategy_rationale.hpp =================================================================== --- doc/doxygen_input/pages/doxygen_c_strategy_rationale.hpp (revision 58155) +++ doc/doxygen_input/pages/doxygen_c_strategy_rationale.hpp (working copy) @@ -39,7 +39,7 @@ The strategy needs to access construction information (member variables), its calculation method is therefore usually not a static method but a non-static const method. It can then access member variables, while still being const, non-mutable, stateless, being able to be called across several function calls. If often has to keep some calculation information (state), so it should (for some algorithms) declare a state_type. In those cases, that state_type is instantiated before first call and specified in each call. -The calculation method is always called \b apply (as convention in GGL) and gets the most elementary information as a parameter: a point, a segment, a range. It depends on the algorithm and, sometimes, on the source geometry passed. That should actually be the case as least as possisble +The calculation method is always called \b apply (as convention in GGL) and gets the most elementary information as a parameter: a point, a segment, a range. It depends on the algorithm and, sometimes, on the source geometry passed. That should actually be the case as infrequent as possible. In most cases, there is an additional method \b result which returns the calculated result. That result-method is a also non-static const method, and the state is passed. Note that the methods might be non-static const, but they might also be static. That is not checked by the concept-checker. @@ -49,7 +49,7 @@ Strategies are checked by a strategy-concept-checker. For this checker (and sometimes for checking alone), they should define some types. Because if no types are defined, the methods cannot be checked at compile time... The strategy-concept-checkers are thus implemented per algorithm and they use the Boost Concept Check Library for checking. -So as explained above, the essention of the design is: +So as explained above, the essence of the design is: - function determines default-strategy, or is called with specified strategy - function calls dispatch (dispatching is done on geometry_tag) - dispatch calls implementation (in namespace detail), which can be shared for different geometry types and for single/multi Index: doc/doxygen_input/pages/doxygen_examples.hpp =================================================================== --- doc/doxygen_input/pages/doxygen_examples.hpp (revision 58155) +++ doc/doxygen_input/pages/doxygen_examples.hpp (working copy) @@ -15,7 +15,7 @@ \example 01_point_example.cpp In most cases the documentation gives small examples of how to use the algorithms or classes. -The point example is a slightly larger example giving the an idea of how to use different +The point example is a slightly larger example giving an idea of how to use different algorithms from the library, related to points. It shows - the usage of include files - how to declare points, using different coordinate types Index: doc/doxygen_input/pages/doxygen_pages.hpp =================================================================== --- doc/doxygen_input/pages/doxygen_pages.hpp (revision 58155) +++ doc/doxygen_input/pages/doxygen_pages.hpp (working copy) @@ -215,7 +215,7 @@ /*! \page DSV DSV (Delimiter Separated Values) -DSV is a text representation of a geometry, explained here: http://en.wikipedia.org/wiki/Delimiter-separated_values +DSV is a text representation of a geometry, explained here: http://en.wikipedia.org/wiki/Delimiter-separated_values. DSV can represent a point, a linestring, a polygon, or multi versions of those. It is currently just a utility in the library, used in samples and tests, to get some textual output @@ -243,7 +243,7 @@ \section Classes OGC defines the following geometry classes, -which are implemented as concepts (and as geometries) the Generic Geometry Library: +which are implemented as concepts (and as geometries) in the Generic Geometry Library: - \ref ggl::point "point": a point. The point defined here is dimensionally agnostic. Library users does not have to use this point, they might also use their own points as long as it meets the concepts. - \ref ggl::linestring "linestring": Sequence of point values with linear interpolation @@ -290,7 +290,7 @@ - In OGC a point is defined by an x-coordinate value, a y-coordinate value and possibly a z-coordinate value and a measured value. In the Generic Geometry Library the basic point defines coordinates in a neutral way, so there is no x, no y. -- in OGC all geometries have additional members, such as SRID, measured. These +- In OGC all geometries have additional members, such as SRID (spatial reference system id) or isMeasured. These properties are not defined in the Generic Geometry Library. Library users can implement them, if necessary, in derived classes. - In OGC the envelope returns a geometry, in the Generic Geometry Library it returns a box @@ -347,9 +347,9 @@ \b Breaking \b changes Because the library was in preview, and it still is, there are some major changes which might influence library user's code. Although there are many changes internally, the changes for users should be relatively small: -- all algorithms accepting linestrings are now modelled to get the linestring itself. In the previous version - the .begin(), end() had to be specified, That is now not necessary anymore because the Boost Range Library is used - internally, and tag dispatching is used to distinguish geometries internally +- all algorithms accepting linestrings are now modified to get the linestring itself. In the previous version + .begin(), .end() had to be specified. This is not necessary anymore, because the Boost Range Library is used + internally, and tag dispatching is used to distinguish different geometries - the "grow" utility is now splitted into buffer (growing a box with a value was in fact a buffer) and a combine. - there was a generic "get" function with a const ref and a non const ref. This is splitted into "get" and "set" - there might be more changes, please contact if anything is unclear Index: example/03_polygon_example.cpp =================================================================== --- example/03_polygon_example.cpp (revision 58155) +++ example/03_polygon_example.cpp (working copy) @@ -60,7 +60,7 @@ std::cout << "centroid: " << ggl::dsv(cent) << std::endl; - // The number of points have to called per ring separately + // The number of points can only be requested per ring std::cout << "number of points in outer ring: " << poly.outer().size() << std::endl; // Polygons can have one or more inner rings, also called holes, donuts, islands, interior rings.