diff --git a/doc/concept/polygon.qbk b/doc/concept/polygon.qbk index a2de9fd6a..8cce35ff5 100644 --- a/doc/concept/polygon.qbk +++ b/doc/concept/polygon.qbk @@ -15,7 +15,7 @@ [heading Description] [concept Polygon..polygon] -A polygon is ['A polygon is a planar surface defined by one exterior boundary and zero or more interior boundaries] +A polygon is ['A polygon is a planar surface defined by one exterior boundary and zero or more interior boundaries] (__ogc_sf__). So the definition of a Boost.Geometry polygon differs a bit from e.g. Wiki, where a polygon does not have holes. A @@ -27,44 +27,46 @@ polygon of Boost.Geometry is a polygon with or without holes. The Polygon Concept is defined as following: * there must be a specialization of `traits::tag` defining `polygon_tag` as type -* there must be a specialization of `traits::ring_type` defining the type of its exterior ring and interior rings as type -* this type defined by `ring_type` must fulfill the [link geometry.reference.concepts.concept_ring Ring Concept] -* there must be a specialization of `traits::interior_type` defining the type of the collection of its interior rings as type; - this collection itself must fulfill a Boost.Range Random Access Range Concept +* there must be a specialization of `traits::ring_mutable_type` defining the mutable types of its exterior and interior rings as type +* there must be a specialization of `traits::ring_const_type` defining the constant types of its exterior and interior rings as type +* `traits::ring_mutable_type` and `traits::ring_const_type` must fulfill the [link geometry.reference.concepts.concept_ring Ring Concept] +* there must be a specialization of `traits::interior_mutable_type` defining the mutable type of the collection of its interior rings as type; +* there must be a specialization of `traits::interior_const_type` defining the constant type of the collection of its interior rings as type; + each of these collections itself must fulfill a Boost.Range Random Access Range Concept * there must be a specialization of `traits::exterior_ring` with two functions named `get`, returning the exterior ring, one being const, the other being non const * there must be a specialization of `traits::interior_rings` with two functions named `get`, returning the interior rings, one being const, the other being non const [heading Rules] -Besides the Concepts, which are checks on compile-time, there are some other -rules that valid polygons must fulfill. This follows the opengeospatial rules (see link +Besides the Concepts, which are checks on compile-time, there are some other +rules that valid polygons must fulfill. This follows the opengeospatial rules (see link above). * Polygons are simple geometric objects (See also [@http://en.wikipedia.org/wiki/Simple_polygon wiki] but holes are allowed in __boost_geometry__ polygons). * If the polygons underlying `ring_type` is defined as clockwise, the exterior - ring must have the clockwise orientation, and any interior ring must be - reversed w.r.t. the defined orientation (so: counter clockwise for clockwise exterior rings). + ring must have the clockwise orientation, and any interior ring must be + reversed w.r.t. the defined orientation (so: counter clockwise for clockwise exterior rings). If the `ring_type` is defined counter clockwise, it is vice versa. * If the polygons underlying `ring_type` is defined as closed, all rings must be closed: the first point must be spatially equal to the last point. * The interior is a connected point set. -* There should be no self intersections, but self tangencies (between +* There should be no self intersections, but self tangencies (between exterior/interior rings) are allowed (as long as the interior is a connected point set. * There should be no cut lines, spikes or punctures. * The interior rings should be located within the exterior ring. Interior rings may not be located within each other. -The algorithms such as intersection, area, centroid, union, etc. do not check -validity. There will be an algorithm is_valid which checks for +The algorithms such as intersection, area, centroid, union, etc. do not check +validity. There will be an algorithm is_valid which checks for validity against these rules, at runtime, and which can be called (by the library user) before. If the input is invalid, the output might be invalid too. For example: if a polygon which should be closed is not closed, the area will be incorrect. -[heading Available Models] +[heading Available Models] * [link geometry.reference.models.model_polygon polygon] * a Boost.Polygon polygon_with_holes_data (requires `#include boost/geometry/geometries/adapted/boost_polygon/polygon.hpp>`) diff --git a/doc/html/index.html b/doc/html/index.html index 5a7a6ed41..175ec69c2 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -3,7 +3,7 @@ Chapter 1. Geometry - + @@ -150,7 +150,7 @@ - +

Last revised: July 28, 2022 at 11:11:09 GMT

Last revised: November 17, 2022 at 14:54:40 GMT
diff --git a/include/boost/geometry/geometries/concepts/box_concept.hpp b/include/boost/geometry/geometries/concepts/box_concept.hpp index de7572a93..c96d39f6a 100644 --- a/include/boost/geometry/geometries/concepts/box_concept.hpp +++ b/include/boost/geometry/geometries/concepts/box_concept.hpp @@ -30,21 +30,6 @@ namespace boost { namespace geometry { namespace concepts { - -/*! -\brief Box concept -\ingroup concepts -\par Formal definition: -The box concept is defined as following: -- there must be a specialization of traits::tag defining box_tag as type -- there must be a specialization of traits::point_type to define the - underlying point type (even if it does not consist of points, it should define - this type, to indicate the points it can work with) -- there must be a specialization of traits::indexed_access, per index - (min_corner, max_corner) and per dimension, with two functions: - - get to get a coordinate value - - set to set a coordinate value (this one is not checked for ConstBox) -*/ template class Box { diff --git a/include/boost/geometry/geometries/concepts/linestring_concept.hpp b/include/boost/geometry/geometries/concepts/linestring_concept.hpp index c9adf1d44..49dc8b221 100644 --- a/include/boost/geometry/geometries/concepts/linestring_concept.hpp +++ b/include/boost/geometry/geometries/concepts/linestring_concept.hpp @@ -35,45 +35,6 @@ namespace boost { namespace geometry { namespace concepts { - -/*! -\brief Linestring concept -\ingroup concepts -\par Formal definition: -The linestring concept is defined as following: -- there must be a specialization of traits::tag defining linestring_tag as type -- it must behave like a Boost.Range -- it must implement a std::back_insert_iterator - - either by implementing push_back - - or by specializing std::back_insert_iterator - -\note to fulfill the concepts, no traits class has to be specialized to -define the point type. - -\par Example: - -A custom linestring, defining the necessary specializations to fulfill to the concept. - -Suppose that the following linestring is defined: -\dontinclude doxygen_5.cpp -\skip custom_linestring1 -\until }; - -It can then be adapted to the concept as following: -\dontinclude doxygen_5.cpp -\skip adapt custom_linestring1 -\until }} - -\note -- There is also the registration macro BOOST_GEOMETRY_REGISTER_LINESTRING -- For registration of std::vector

(and deque, and list) it is enough to -include the header-file geometries/adapted/std_as_linestring.hpp. That registers -a vector as a linestring (so it cannot be registered as a linear ring then, -in the same source code). - - -*/ - template class Linestring { diff --git a/include/boost/geometry/geometries/concepts/multi_linestring_concept.hpp b/include/boost/geometry/geometries/concepts/multi_linestring_concept.hpp index 26b86eca7..9549a229f 100644 --- a/include/boost/geometry/geometries/concepts/multi_linestring_concept.hpp +++ b/include/boost/geometry/geometries/concepts/multi_linestring_concept.hpp @@ -31,18 +31,6 @@ namespace boost { namespace geometry { namespace concepts { - -/*! -\brief multi-linestring concept -\ingroup concepts -\par Formal definition: -The multi linestring concept is defined as following: -- there must be a specialization of traits::tag defining multi_linestring_tag as - type -- it must behave like a Boost.Range -- its range value must fulfil the Linestring concept - -*/ template class MultiLinestring { diff --git a/include/boost/geometry/geometries/concepts/multi_point_concept.hpp b/include/boost/geometry/geometries/concepts/multi_point_concept.hpp index da1991d65..23534deee 100644 --- a/include/boost/geometry/geometries/concepts/multi_point_concept.hpp +++ b/include/boost/geometry/geometries/concepts/multi_point_concept.hpp @@ -33,17 +33,6 @@ namespace boost { namespace geometry { namespace concepts { - -/*! -\brief MultiPoint concept -\ingroup concepts -\par Formal definition: -The multi point concept is defined as following: -- there must be a specialization of traits::tag defining multi_point_tag as type -- it must behave like a Boost.Range -- its range value must fulfil the Point concept - -*/ template class MultiPoint { diff --git a/include/boost/geometry/geometries/concepts/multi_polygon_concept.hpp b/include/boost/geometry/geometries/concepts/multi_polygon_concept.hpp index 5118502c1..886bf3e88 100644 --- a/include/boost/geometry/geometries/concepts/multi_polygon_concept.hpp +++ b/include/boost/geometry/geometries/concepts/multi_polygon_concept.hpp @@ -31,18 +31,6 @@ namespace boost { namespace geometry { namespace concepts { - -/*! -\brief multi-polygon concept -\ingroup concepts -\par Formal definition: -The multi polygon concept is defined as following: -- there must be a specialization of traits::tag defining multi_polygon_tag - as type -- it must behave like a Boost.Range -- its range value must fulfil the Polygon concept - -*/ template class MultiPolygon { diff --git a/include/boost/geometry/geometries/concepts/point_concept.hpp b/include/boost/geometry/geometries/concepts/point_concept.hpp index 5657f9f71..dbe004a58 100644 --- a/include/boost/geometry/geometries/concepts/point_concept.hpp +++ b/include/boost/geometry/geometries/concepts/point_concept.hpp @@ -35,63 +35,6 @@ namespace boost { namespace geometry { namespace concepts { -/*! -\brief Point concept. -\ingroup concepts - -\par Formal definition: -The point concept is defined as following: -- there must be a specialization of traits::tag defining point_tag as type -- there must be a specialization of traits::coordinate_type defining the type - of its coordinates -- there must be a specialization of traits::coordinate_system defining its - coordinate system (cartesian, spherical, etc) -- there must be a specialization of traits::dimension defining its number - of dimensions (2, 3, ...) (derive it conveniently - from std::integral_constant<std::size_t, X> for X-D) -- there must be a specialization of traits::access, per dimension, - with two functions: - - \b get to get a coordinate value - - \b set to set a coordinate value (this one is not checked for ConstPoint) -- for non-Cartesian coordinate systems, the coordinate system's units - must either be boost::geometry::degree or boost::geometry::radian - - -\par Example: - -A legacy point, defining the necessary specializations to fulfil to the concept. - -Suppose that the following point is defined: -\dontinclude doxygen_5.cpp -\skip legacy_point1 -\until }; - -It can then be adapted to the concept as following: -\dontinclude doxygen_5.cpp -\skip adapt legacy_point1 -\until }} - -Note that it is done like above to show the system. Users will normally use the registration macro. - -\par Example: - -A read-only legacy point, using a macro to fulfil to the ConstPoint concept. -It cannot be modified by the library but can be used in all algorithms where -points are not modified. - -The point looks like the following: - -\dontinclude doxygen_5.cpp -\skip legacy_point2 -\until }; - -It uses the macro as following: -\dontinclude doxygen_5.cpp -\skip adapt legacy_point2 -\until end adaptation - -*/ - template class Point { diff --git a/include/boost/geometry/geometries/concepts/ring_concept.hpp b/include/boost/geometry/geometries/concepts/ring_concept.hpp index 7afbc4e18..b4cf961ad 100644 --- a/include/boost/geometry/geometries/concepts/ring_concept.hpp +++ b/include/boost/geometry/geometries/concepts/ring_concept.hpp @@ -34,22 +34,6 @@ namespace boost { namespace geometry { namespace concepts { - -/*! -\brief ring concept -\ingroup concepts -\par Formal definition: -The ring concept is defined as following: -- there must be a specialization of traits::tag defining ring_tag as type -- it must behave like a Boost.Range -- there can optionally be a specialization of traits::point_order defining the - order or orientation of its points, clockwise or counterclockwise. -- it must implement a std::back_insert_iterator - (This is the same as the for the concept Linestring, and described there) - -\note to fulfill the concepts, no traits class has to be specialized to -define the point type. -*/ template class Ring { diff --git a/include/boost/geometry/geometries/concepts/segment_concept.hpp b/include/boost/geometry/geometries/concepts/segment_concept.hpp index 024076421..7dac9e3ed 100644 --- a/include/boost/geometry/geometries/concepts/segment_concept.hpp +++ b/include/boost/geometry/geometries/concepts/segment_concept.hpp @@ -32,25 +32,6 @@ namespace boost { namespace geometry { namespace concepts { - -/*! -\brief Segment concept. -\ingroup concepts -\details Formal definition: -The segment concept is defined as following: -- there must be a specialization of traits::tag defining segment_tag as type -- there must be a specialization of traits::point_type to define the - underlying point type (even if it does not consist of points, it should define - this type, to indicate the points it can work with) -- there must be a specialization of traits::indexed_access, per index - and per dimension, with two functions: - - get to get a coordinate value - - set to set a coordinate value (this one is not checked for ConstSegment) - -\note The segment concept is similar to the box concept, defining another tag. -However, the box concept assumes the index as min_corner, max_corner, while -for the segment concept there is no assumption. -*/ template class Segment {