diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt
index 64d3604362f..0287ab3226c 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt
@@ -285,18 +285,18 @@ classes built on top of the halfedge data structure.
The \f$x\f$-monotone curves of an arrangement are embedded in a
rectangular two-dimensional area called the parameter space. The
-parameter space is defined as \f$ X \times Y\f$, where \f$ X\f$ and
-\f$ Y\f$ are open, half-open, or closed intervals with endpoints in
-the compactified real line \f$ \mathbb{R} \cup
-\{-\infty,+\infty\}\f$. Let \f$x_{\rm min}\f$, \f$x_{\rm max}\f$,
-\f$y_{\rm min}\f$, and \f$y_{\rm max}\f$ denote the endpoints of \f$
-X\f$ and \f$ Y\f$, respectively. We typically refer to these values as
-the left, right, bottom, and top sides of the boundary of the
-parameter space. If the parameter space is, for example, the entire
-compactified plane, as in the case of arrangements in the plane,
-\f$x_{\rm min} = y_{\rm min} = -\infty\f$ and \f$x_{\rm max} = y_{\rm
-max} = +\infty\f$; see Section \ref aos_sec-curved_surfaces for more
-details.
+parameter space is defined as \f$X \times Y\f$, where \f$X\f$ and
+\f$Y\f$ are open, half-open, or closed intervals with endpoints in the
+compactified real line \f$\mathbb{R} \cup \{-\infty,+\infty\}\f$. Let
+\f$x_{\rm min}\f$, \f$x_{\rm max}\f$, \f$y_{\rm min}\f$, and
+\f$y_{\rm max}\f$ denote the endpoints of \f$X\f$ and \f$Y\f$,
+respectively. We typically refer to these values as the left, right,
+bottom, and top sides of the boundary of the parameter space. If the
+parameter space is, for example, the entire compactified plane, as in
+the case of arrangements in the plane,
+\f$x_{\rm min} = y_{\rm min} = -\infty\f$ and
+\f$x_{\rm max} = y_{\rm max} = +\infty\f$; see Section \ref
+aos_sec-curved_surfaces for more details.
\cgalAdvancedEnd
@@ -350,20 +350,20 @@ theoretically, the former are degenerate holes. See
\cgalFigureBegin{aos_fig-arr_segs,arr_segs.png}
An arrangement of interior-disjoint line segments with some of the
-\dcel records that represent it. The unbounded face \f$ f_0\f$ has
+\dcel records that represent it. The unbounded face \f$f_0\f$ has
a single connected component that forms a hole inside it, and this
-hole comprises of several faces. The halfedge \f$ e\f$ is directed
-from its source vertex \f$ v_1\f$ to its target vertex \f$
-v_2\f$. This edge, together with its twin \f$ e'\f$, correspond to a
-line segment that connects the points associated with \f$ v_1\f$ and
-\f$ v_2\f$ and separates the face \f$ f_1\f$ from \f$ f_2\f$. The
-predecessor \f$ e_{\rm prev}\f$ and successor \f$ e_{\rm next}\f$ of
-\f$ e\f$ are part of the chain that form the outer boundary of the
-face \f$ f_2\f$. The face \f$ f_1\f$ has a more complicated structure
+hole comprises of several faces. The halfedge \f$e\f$ is directed
+from its source vertex \f$v_1\f$ to its target vertex \f$v_2\f$.
+This edge, together with its twin \f$e'\f$, correspond to a
+line segment that connects the points associated with \f$v_1\f$ and
+\f$v_2\f$ and separates the face \f$f_1\f$ from \f$f_2\f$. The
+predecessor \f$e_{\rm prev}\f$ and successor \f$e_{\rm next}\f$ of
+\f$e\f$ are part of the chain that form the outer boundary of the
+face \f$f_2\f$. The face \f$f_1\f$ has a more complicated structure
as it contains two holes in its interior: One hole consists of two
-adjacent faces \f$ f_3\f$ and \f$ f_4\f$, while the other hole
-comprises of two edges. \f$ f_1\f$ also contains two isolated vertices
-\f$ u_1\f$ and \f$ u_2\f$ in its interior.
+adjacent faces \f$f_3\f$ and \f$f_4\f$, while the other hole
+comprises of two edges. \f$f_1\f$ also contains two isolated vertices
+\f$u_1\f$ and \f$u_2\f$ in its interior.
\cgalFigureEnd
@@ -392,12 +392,12 @@ the `Arrangement_2` class template; their description follows.
- The `Traits` template-parameter should be substituted by a
- model of the `ArrangementBasicTraits_2` concept and optionally
+ model of the `AosBasicTraits_2` concept and optionally
additional geometry traits concepts. A model of the
- `ArrangementBasicTraits_2` concept defines the types of
+ `AosBasicTraits_2` concept defines the types of
\f$x\f$-monotone curves and two-dimensional points, namely
- `ArrangementBasicTraits_2::X_monotone_curve_2` and
- `ArrangementBasicTraits_2::Point_2`, respectively, and supports
+ `AosBasicTraits_2::X_monotone_curve_2` and
+ `AosBasicTraits_2::Point_2`, respectively, and supports
basic geometric predicates on them. The instantiated traits class
determines the family of planar curves that induce the arrangement.
@@ -417,7 +417,7 @@ the `Arrangement_2` class template; their description follows.
in Section \ref aos_sec-geom_traits.
- The `Dcel` template-parameter should be substituted by a class
- that models the `ArrangementDcel` concept, which is used to represent
+ that models the `AosDcel` concept, which is used to represent
the topological layout of the arrangement. This parameter is
substituted by `Arr_default_dcel` by default, and
we use this default value in this and in the following three
@@ -487,12 +487,12 @@ results.
#include
#include
-typedef int Number_type;
-typedef CGAL::Cartesian Kernel;
-typedef CGAL::Arr_non_caching_segment_traits_2 Traits;
-typedef Traits_2::Point_2 Point;
-typedef Traits_2::X_monotone_curve_2 Segment;
-typedef CGAL::Arrangement_2 Arrangement;
+using Number_type = int;
+using Kernel = CGAL::Cartesian;
+using Traits = CGAL::Arr_non_caching_segment_traits_2;
+using Point = Traits_2::Point_2;
+using Segment = Traits_2::X_monotone_curve_2;
+using Arrangement = CGAL::Arrangement_2;
int main() {
Arrangement arr;
@@ -767,7 +767,7 @@ void print_face(typename Arrangement::Face_const_handle f) {
}
// Print the boundary of each of the holes.
- size_t index = 1;
+ std::size_t index = 1;
for (auto hi = f->holes_begin(); hi != f->holes_end(); ++hi) {
std::cout << " Hole #" << index++ << ": ";
print_ccb(*hi);
@@ -1018,17 +1018,17 @@ exact manner.
#include
#include
-typedef CGAL::Exact_predicates_inexact_constructions_kernel Kernel;
-typedef Kernel::FT Number_type;
+using Kernel = CGAL::Exact_predicates_inexact_constructions_kernel;
+using Number_type = Kernel::FT;
-typedef CGAL::Arr_non_caching_segment_traits_2 Traits;
-typedef Traits::Point_2 Point;
-typedef Traits::X_monotone_curve_2 Segment;
+using Traits = CGAL::Arr_non_caching_segment_traits_2;
+using Point = Traits::Point_2;
+using Segment = Traits::X_monotone_curve_2;
-typedef CGAL::Arrangement_2 Arrangement;
-typedef Arrangement::Vertex_handle Vertex_handle;
-typedef Arrangement::Halfedge_handle Halfedge_handle;
-typedef Arrangement::Face_handle Face_handle;
+using Arrangement = CGAL::Arrangement_2;
+using Vertex_handle = Arrangement::Vertex_handle;
+using Halfedge_handle = Arrangement::Halfedge_handle;
+using Face_handle = Arrangement::Face_handle;
\endcode
@@ -1040,7 +1040,7 @@ the member functions that manipulate them are easier to understand.
The call \link Arrangement_on_surface_2::insert_in_face_interior()
`arr.insert_in_face_interior(p, f)`\endlink inserts an isolated point
-\f$p\f$, located in the interior of a given face \f$ f\f$, into the
+\f$p\f$, located in the interior of a given face \f$f\f$, into the
arrangement and returns a handle to the arrangement vertex associated
with \f$p\f$ it has created. Naturally, this function has a
precondition that \f$p\f$ is really an isolated point; namely it does
@@ -1305,10 +1305,10 @@ geometric algorithms that operate on it. Thus, the `Arrangement_2`
class template does not support point-location queries directly.
Instead, the \ref PkgArrangementOnSurface2 package provides a set of
class templates that are capable of answering such queries; all are
-models of the concept `ArrangementPointLocation_2`. Each model employs
+models of the concept `AosPointLocation_2`. Each model employs
a different algorithm or strategy for answering queries. A
model of this concept must define the \link
-ArrangementPointLocation_2::locate() `locate()`\endlink member
+AosPointLocation_2::locate() `locate()`\endlink member
function, which accepts an input query-point and returns a polymorphic
object representing the arrangement cell that contains this point.
The returned object is of type
@@ -1325,7 +1325,7 @@ the appropriate handle can be obtained with value retrieval
by `std::get` as demonstrated in the example below.
Note that the handles returned by the \link
-ArrangementPointLocation_2::locate() `locate()`\endlink functions are
+AosPointLocation_2::locate() `locate()`\endlink functions are
non-mutable (`const`). If necessary, such handles may be cast to
mutable handles using the
`Arrangement_on_surface_2::non_const_handle()` methods.
@@ -1338,7 +1338,7 @@ when `pl` is constructed or at a later time using the
The function template `locate_point()` listed below accepts a
point-location object, the type of which is a model of the
-`ArrangementPointLocation_2` concept, and a query point. The function
+`AosPointLocation_2` concept, and a query point. The function
template issues a point-location query for the given point, and prints
out the result. It is defined in the header file
`point_location_utils.h`.
@@ -1347,10 +1347,9 @@ out the result. It is defined in the header file
\code
template
void locate_point(const PointLocation& pl,
- const typename PointLocation::Arrangement_2::Point_2& q)
-{
- typedef PointLocation Point_location;
- typedef typename Point_location::Arrangement_2 Arrangement_2;
+ const typename PointLocation::Arrangement_2::Point_2& q) {
+ using Point_location = PointLocation;
+ using Arrangement_2 = typename Point_location::Arrangement_2;
typename CGAL::Arr_point_location_result::Type obj =
pl.locate(q);
@@ -1372,13 +1371,12 @@ to an arrangement.
template
void print_point_location
(const typename PointLocation::Arrangement_::Point_2& q
- typename CGAL::Arr_point_location_result::Type obj)
-{
- typedef Arrangement_ Arrangement_2;
+ typename CGAL::Arr_point_location_result::Type obj) {
+ using Arrangement_2 = Arrangement_;
- typedef typename Arrangement_2::Vertex_const_handle Vertex_const_handle;
- typedef typename Arrangement_2::Halfedge_const_handle Halfedge_const_handle;
- typedef typename Arrangement_2::Face_const_handle Face_const_handle;
+ using Vertex_const_handle = typename Arrangement_2::Vertex_const_handle;
+ using Halfedge_const_handle = typename Arrangement_2::Halfedge_const_handle;
+ using Face_const_handle = typename Arrangement_2::Face_const_handle;
const Vertex_const_handle* v;
const Halfedge_const_handle* e;
@@ -1439,9 +1437,9 @@ vary according to the user choice.} for answering queries:
Reference Manual for more details.
The arrangement attached to the landmark strategy must be either (i)
- an instance of the `Arrangement_2` class template, where
- the `Traits` parameter is substituted by a geometry-traits class
- that models the `ArrangementLandmarkTraits_2` concept, or (ii) an
+ an instance of the `Arrangement_2` class template,
+ where the `GeomTraits` parameter is substituted by a geometry-traits
+ class that models the `AosLandmarkTraits_2` concept, or (ii) an
instance of the `Arrangement_on_surface_2`
class template, where the `GeomTraits` is similarly substituted;
see Section \ref aos_sssec-tr_landmarks_concept for details about
@@ -1560,7 +1558,7 @@ that it hits a vertex, or that the arrangement does not have any
vertex or edge lying directly above (or below) the query point.
All point-location classes listed in the previous section are also
-models of the `ArrangementVerticalRayShoot_2` concept. That is, they
+models of the `AosVerticalRayShoot_2` concept. That is, they
all have member functions called `ray_shoot_up(q)` and
`ray_shoot_down(q)` that accept a query point \f$q\f$. These functions
output a polymorphic object of type
@@ -1577,7 +1575,7 @@ directly above (or below) \f$q\f$.
The function template `vertical_ray_shooting_query()` listed
below accepts a vertical ray-shooting object, the type of which
-models the `ArrangementVerticalRayShoot_2` concept. It exports
+models the `AosVerticalRayShoot_2` concept. It exports
the result of the upward vertical ray-shooting operation from a
given query point to the standard output-stream. The ray-shooting
object `vrs` is assumed to be already attached to an arrangement.
@@ -1588,18 +1586,17 @@ The function template is defined in the header file
template
void shoot_vertical_ray(const RayShoot& vrs,
const typename
- VerticalRayShooting::Arrangement_2::Point_2& q)
-{
- typedef VerticalRayShooting Vertical_ray_shooting;
+ VerticalRayShooting::Arrangement_2::Point_2& q) {
+ using Vertical_ray_shooting = VerticalRayShooting;
// Perform the point-location query.
typename Vertical_ray_shooting::result_type obj = vrs.ray_shoot_up(q);
// Print the result.
- typedef typename Vertical_ray_shooting::Arrangement_2 Arrangement_2;
- typedef typename Arrangement_2::Vertex_const_handle Vertex_const_handle;
- typedef typename Arrangement_2::Halfedge_const_handle Halfedge_const_handle;
- typedef typename Arrangement_2::Face_const_handle Face_const_handle;
+ using Arrangement_2 = typename Vertical_ray_shooting::Arrangement_2;
+ using Vertex_const_handle = typename Arrangement_2::Vertex_const_handle;
+ using Halfedge_const_handle = typename Arrangement_2::Halfedge_const_handle;
+ using Face_const_handle = typename Arrangement_2::Face_const_handle;
const Vertex_const_handle* v;
const Halfedge_const_handle* e;
@@ -1685,7 +1682,7 @@ namely the surface sweep and the zone construction.
These operations accepts \f$x\f$-monotone curves; thus, the
geometry-traits class used by the arrangements passed as input to, or
obtained as output from, these operations must be a model of the
-`ArrangementXMonotoneTraits_2` concept; see Section \ref
+`AosXMonotoneTraits_2` concept; see Section \ref
aos_sec-geom_traits for the precise definition of this concept. It
defines the minimal set of geometric primitives, among other things,
required to perform the algorithms of the surface-sweep and
@@ -1746,13 +1743,13 @@ location.\cgalFootnote{The \cgalFootnoteCode{CGAL::insert_non_intersecting_curve
function template, as all other functions reviewed in this section, is
parameterized by an arrangement type and a point-location type (The
latter must be substituted by a model of the
-`ArrangementPointLocation_2` concept).} The insertion operation thus
+`AosPointLocation_2` concept).} The insertion operation thus
hardly requires any geometric operations on top of the ones needed to
answer the point-location queries. Moreover, it is sufficient that the
traits class that substitutes the `Traits` template parameter of the
`Arrangement_2` class template when the latter is
-instantiated models the concept `ArrangementBasicTraits_2` concept
-(and the concept `ArrangementLandmarkTraits_2` if the landmark
+instantiated models the concept `AosBasicTraits_2` concept
+(and the concept `AosLandmarkTraits_2` if the landmark
point-location strategy is used), and does not have to support the
computation of intersection points between curves. This implies that
using a kernel that provides exact geometric predicates, but
@@ -1780,7 +1777,7 @@ function relatively efficient; however, its preconditions on the input
curves are still rather restricting. Let us assume that the traits
class that substitutes the `Traits` template parameter of the
`Arrangement_2` class template models the refined
-`ArrangementXMonotoneTraits_2` concept and supports curve intersection
+`AosXMonotoneTraits_2` concept and supports curve intersection
computations; see Section \ref aos_sec-geom_traits for the exact
details. Given an \f$x\f$-monotone curve, it is sufficient to locate
its left endpoint in the arrangement and to trace its zone
@@ -1850,10 +1847,10 @@ pl)`\endlink, where \f$c\f$ is not necessarily \f$x\f$-monotone. In
this case the type of `arr` must be an instance of the
`Arrangement_2` class template, where the `Traits`
template parameter is substituted by a traits class that models the
-concept `ArrangementTraits_2`, which refines the
-`ArrangementXMonotoneTraits_2` concept. It has to define an additional
-\link ArrangementTraits_2::Curve_2 `Curve_2`\endlink type, which may
-differ from the \link ArrangementBasicTraits_2::X_monotone_curve_2
+concept `AosTraits_2`, which refines the
+`AosXMonotoneTraits_2` concept. It has to define an additional
+\link AosTraits_2::Curve_2 `Curve_2`\endlink type, which may
+differ from the \link AosBasicTraits_2::X_monotone_curve_2
`X_monotone_curve_2`\endlink type. It also has to support the
subdivision of curves of this new type into \f$x\f$-monotone curves
and possibly singular points; see the exact details in Section \ref
@@ -1894,7 +1891,7 @@ associated with \f$p\f$.
The type of `arr` must be and instance of the `Arrangement_2` class
template instantiated with a traits class that models the
-`ArrangementXMonotoneTraits_2` concept, as the insertion operation may
+`AosXMonotoneTraits_2` concept, as the insertion operation may
involve the splitting of curves.
@@ -1958,7 +1955,7 @@ use the zone framework.
The free function template `%CGAL::do_intersect<>(arr, c, pl)` checks
whether the given query curve \f$c\f$ intersects the curves and points
of an existing arrangement `arr`. If \f$c\f$ is not \f$x\f$-monotone
-(that is, it is of type \link ArrangementTraits_2::Curve_2
+(that is, it is of type \link AosTraits_2::Curve_2
`Curve_2`\endlink) the curve is subdivided into \f$x\f$-monotone
subcurves and isolated points. Each \f$x\f$-monotone curve (or point)
is checked for intersection in turn using the zone framework. For
@@ -1973,9 +1970,9 @@ user-defined point-location object, it constructs a local object of
the walk point-location type, namely, an instance of the
`Arr_walk_along_line_point_location` class template, and uses it to
locate the endpoint. If the given curve is \f$x\f$-monotone then the
-traits type must model the `ArrangementXMonotoneTraits_2` concept. If
+traits type must model the `AosXMonotoneTraits_2` concept. If
the curve is not \f$x\f$-monotone then the traits type must model the
-`ArrangementTraits_2` concept.
+`AosTraits_2` concept.
The `CGAL::zone<>(arr, c, oi, pl)` function template computes the zone
of a given \f$x\f$-monotone curve in a given arrangement. More
@@ -1988,7 +1985,7 @@ that instead of accepting a user-defined point-location object, it
constructs a local object of the walk point-location type, namely, an
instance of the `Arr_walk_along_line_point_location` class template,
and uses it to locate the endpoint. The traits type must model the
-`ArrangementXMonotoneTraits_2` concept.
+`AosXMonotoneTraits_2` concept.
\subsection arr_ssec_sweep The Surface-Sweep Algorithm
@@ -2082,7 +2079,7 @@ arrangement of intersecting line segments, as constructed in \ref
Arrangement_on_surface_2/global_insertion.cpp. The segments of
\f$\mathcal{S}_1\f$ are drawn in solid lines and the segments of
\f$\mathcal{S}_2\f$ are drawn in dark dashed lines. Note that the
-segment \f$ s\f$ (light dashed line) overlaps one of the segments in
+segment \f$s\f$ (light dashed line) overlaps one of the segments in
\f$\mathcal{S}_1\f$. \cgalFigureEnd
@@ -2115,9 +2112,9 @@ below. The three levels, starting from the most restrictive, are
| Type of Curves | Geometry-Traits Concept | Insertion Function
- |
|---|
| \f$x\f$-monotone and pairwise disjoint | `ArrangementBasicTraits_2` or `ArrangementLandmarkTraits_2` | `CGAL::insert_non_intersecting_curve<>()`
- |
| \f$x\f$-monotone | `ArrangementXMonotoneTraits_2` | `%CGAL::insert<>()`
- |
| general | `ArrangementTraits_2` | `%CGAL::insert<>()`
+ |
| \f$x\f$-monotone and pairwise disjoint | `AosBasicTraits_2` or `AosLandmarkTraits_2` | `CGAL::insert_non_intersecting_curve<>()`
+ |
| \f$x\f$-monotone | `AosXMonotoneTraits_2` | `%CGAL::insert<>()`
+ |
| general | `AosTraits_2` | `%CGAL::insert<>()`
|
The insertion function template `%insert()` is overloaded to
@@ -2143,8 +2140,8 @@ form a single curve associated with a single edge. An attempt to
remove a vertex or an edge from an arrangement object `arr` using the
free functions above requires that the traits class used to
instantiate the arrangement type of `arr` models the concept
-`ArrangementXMonotoneTraits_2`, which refines the
-`ArrangementBasicTraits_2` concept; see Section \ref
+`AosXMonotoneTraits_2`, which refines the
+`AosBasicTraits_2` concept; see Section \ref
aos_sec-geom_traits.
The function template `CGAL::remove_vertex<>(arr, v)` removes the
@@ -2536,7 +2533,7 @@ the file `is_in_x_range.h`, checks whether a given point \f$p\f$ is in
the \f$x\f$-range of the curve associated with a given halfedge
\f$e\f$. The function template also exemplifies how some of the above
functions can be used. The traits functor \link
-ArrangementBasicTraits_2::Compare_x_2 `Compare_x_2`\endlink used in
+AosBasicTraits_2::Compare_x_2 `Compare_x_2`\endlink used in
the code is described in Section \ref
aos_sssec-geom_traits-concepts_basic.
@@ -2682,20 +2679,20 @@ next. These types are defined in the header file `arr_linear.h`.
#include
#include
-typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
-typedef Kernel::FT Number_type;
+using Kernel = CGAL::Exact_predicates_exact_constructions_kernel;
+using Number_type = Kernel::FT;
-typedef CGAL::Arr_linear_traits_2 Traits;
-typedef Traits::Point_2 Point;
-typedef Traits::Segment_2 Segment;
-typedef Traits::Ray_2 Ray;
-typedef Traits::Line_2 Line;
-typedef Traits::X_monotone_curve_2 X_monotone_curve;
+using Traits = CGAL::Arr_linear_traits_2;
+using Point = Traits::Point_2;
+using Segment = Traits::Segment_2;
+using Ray = Traits::Ray_2;
+using Line = Traits::Line_2;
+using X_monotone_curve = Traits::X_monotone_curve_2;
-typedef CGAL::Arrangement_2 Arrangement;
-typedef Arrangement::Vertex_handle Vertex_handle;
-typedef Arrangement::Halfedge_handle Halfedge_handle;
-typedef Arrangement::Face_handle Face_handle;
+using Arrangement = CGAL::Arrangement_2;
+using Vertex_handle = Arrangement::Vertex_handle;
+using Halfedge_handle = Arrangement::Halfedge_handle;
+using Face_handle = Arrangement::Face_handle;
\endcode
@@ -2854,7 +2851,7 @@ right sides) are identified if
called an identification curve.
Rectangles, strips, quadrants, half-planes, and planes can be modeled
-with \f$\phi_S \f$ being the identity mapping. For example,
+with \f$\phi_S\f$ being the identity mapping. For example,
\f$\Phi_S(x, y) = (x, y, 0)\f$ with \f$X = Y =(-\infty, +\infty)\f$
parameterizes a plane. Surfaces such as paraboloids can be
modeled through continuous and bijective parameterizations, for
@@ -3055,17 +3052,17 @@ respectively.
If you want to determine whether the pre-image of a point \f$p\f$
lies on identified sides, you need to employ one of the two traits
functors \link
- ArrangementIdentifiedHorizontalTraits_2::Is_on_x_identification_2
+ AosIdentifiedHorizontalTraits_2::Is_on_x_identification_2
`Is_on_x_identification_2`\endlink or \link
- ArrangementIdentifiedVerticalTraits_2::Is_on_y_identification_2
+ AosIdentifiedVerticalTraits_2::Is_on_y_identification_2
`Is_on_y_identification_2`\endlink; see Section \ref
aos_ssec-traits-curved. If the pre-image of an \f$x\f$-monotone
curve \f$c\f$ does not entirely lie on identified sides, you can
determine the location of the pre-image of an endpoint of \f$c\f$
employing either the \link
- ArrangementVerticalSideTraits_2::Parameter_space_in_x_2
+ AosVerticalSideTraits_2::Parameter_space_in_x_2
`Parameter_space_in_x_2`\endlink functor or the \link
- ArrangementHorizontalSideTraits_2::Parameter_space_in_y_2
+ AosHorizontalSideTraits_2::Parameter_space_in_y_2
`Parameter_space_in_y_2`\endlink functors; see Section \ref
aos_ssec-traits-curved. The operations in both functors accept an
enumeration that indicates the curve end, that is,
@@ -3122,20 +3119,20 @@ parameter space are identified and the bottom and top sides are
contracted, which is the settings used by the traits class template
`Arr_geodesic_arc_on_sphere_traits_2`; see Section \ref
arr_ssectr_spherical. The traits functors \link
-ArrangementBasicTraits_2::Construct_min_vertex_2
+AosBasicTraits_2::Construct_min_vertex_2
`Construct_min_vertex_2`\endlink, \link
-ArrangementBasicTraits_2::Construct_max_vertex_2
+AosBasicTraits_2::Construct_max_vertex_2
`Construct_min_vertex_2`\endlink, and \link
-ArrangementBasicTraits_2::Compare_x_2 `Compare_x_2`\endlink used in
+AosBasicTraits_2::Compare_x_2 `Compare_x_2`\endlink used in
the code are described is Section \ref
aos_sssec-geom_traits-concepts_basic. The traits functors \link
-ArrangementVerticalSideTraits_2::Parameter_space_in_x_2
+AosVerticalSideTraits_2::Parameter_space_in_x_2
`Parameter_space_in_x_2`\endlink, \link
-ArrangementHorizontalSideTraits_2::Parameter_space_in_y_2
+AosHorizontalSideTraits_2::Parameter_space_in_y_2
`Parameter_space_in_y_2`\endlink, \link
-ArrangementIdentifiedVerticalTraits_2::Is_on_y_identification_2
+AosIdentifiedVerticalTraits_2::Is_on_y_identification_2
`Is_on_y_identification_2`\endlink, and \link
-ArrangementHorizontalSideTraits_2::Compare_x_on_boundary_2
+AosHorizontalSideTraits_2::Compare_x_on_boundary_2
`Compare_x_on_boundary_2`\endlink, are described is Section \ref
aos_ssec-traits-curved.
@@ -3255,10 +3252,10 @@ The hierarchy of the main geometry traits concepts.
\subsubsection aos_sssec-geom_traits-concepts_basic The Basic Concept
-A model of the basic concept `ArrangementBasicTraits_2` needs to
-define the types \link ArrangementBasicTraits_2::Point_2
+A model of the basic concept `AosBasicTraits_2` needs to
+define the types \link AosBasicTraits_2::Point_2
`Point_2`\endlink and \link
-ArrangementBasicTraits_2::X_monotone_curve_2
+AosBasicTraits_2::X_monotone_curve_2
`X_monotone_curve_2`\endlink, where objects of the former type are the
geometric mapping of arrangement vertices, and objects of the latter
type are the geometric mapping of edges. In addition, it has to
@@ -3269,20 +3266,20 @@ and points that do not lie in the interiors of the curves. The basic
set of predicates is also sufficient for answering vertical
ray-shooting queries and point-location queries with a small
exception: Locating a point using the landmark strategy requires a
-traits class that models the concept `ArrangementLandmarkTraits_2`;
+traits class that models the concept `AosLandmarkTraits_2`;
see Section \ref aos_sssec-tr_landmarks_concept.
-- \link ArrangementBasicTraits_2::Compare_x_2 `Compare_x_2`\endlink:
+
- \link AosBasicTraits_2::Compare_x_2 `Compare_x_2`\endlink:
- Compares the \f$x\f$-coordinates of two points.
-
- \link ArrangementBasicTraits_2::Compare_xy_2 `Compare_xy_2`\endlink:
+
- \link AosBasicTraits_2::Compare_xy_2 `Compare_xy_2`\endlink:
- Compares two points lexicographically, first by their
\f$x\f$-coordinates, and if they are equal, by their
\f$y\f$-coordinates.
-
- \link ArrangementBasicTraits_2::Equal_2 `Equal_2`\endlink:
+
- \link AosBasicTraits_2::Equal_2 `Equal_2`\endlink:
- There are two overloaded Boolean operators that test equality. One
returns true iff two given points represent the same geometric point
in the two-dimensional surface, and the second returns true iff the
@@ -3291,36 +3288,36 @@ see Section \ref aos_sssec-tr_landmarks_concept.
of two \f$x\f$-monotone curves is used only for testing as part of
the test suite.}
-
- \link ArrangementBasicTraits_2::Construct_min_vertex_2 `Construct_min_vertex_2`\endlink:
+
- \link AosBasicTraits_2::Construct_min_vertex_2 `Construct_min_vertex_2`\endlink:
- Returns the lexicographically smallest (or left) endpoint of an
\f$x\f$-monotone curve.
-
- \link ArrangementBasicTraits_2::Construct_max_vertex_2 `Construct_max_vertex_2`\endlink:
+
- \link AosBasicTraits_2::Construct_max_vertex_2 `Construct_max_vertex_2`\endlink:
- Returns the lexicographically largest (or right) endpoint of an
\f$x\f$-monotone curve.
-
- \link ArrangementBasicTraits_2::Is_vertical_2 `Is_vertical_2`\endlink:
+
- \link AosBasicTraits_2::Is_vertical_2 `Is_vertical_2`\endlink:
- Determines whether an \f$x\f$-monotone curve is vertical.
-
- \link ArrangementBasicTraits_2::Compare_y_at_x_2 `Compare_y_at_x_2`\endlink:
+
- \link AosBasicTraits_2::Compare_y_at_x_2 `Compare_y_at_x_2`\endlink:
- Given an \f$x\f$-monotone curve \f$c\f$ and a point \f$p\f$ that
lies in the \f$x\f$-range of \f$c\f$, determines whether \f$p\f$ is
below, above or lies on \f$c\f$.
-
- \link ArrangementBasicTraits_2::Compare_y_at_x_right_2 `Compare_y_at_x_right_2`\endlink:
+
- \link AosBasicTraits_2::Compare_y_at_x_right_2 `Compare_y_at_x_right_2`\endlink:
- Given two \f$x\f$-monotone curves \f$c_1\f$ and \f$c_2\f$ that
share a common minimal (left) endpoint \f$p\f$, determines whether
\f$c_1\f$ is above or below \f$c_2\f$ immediately to the right of
\f$p\f$, or whether the two curves overlap there.
-Every model of the concept `ArrangementBasicTraits_2` needs to define
-a nested type named \link ArrangementBasicTraits_2::Has_left_category
+Every model of the concept `AosBasicTraits_2` needs to define
+a nested type named \link AosBasicTraits_2::Has_left_category
`Has_left_category`\endlink. It determines whether the traits class
supports the following predicate:
-- \link ArrangementBasicTraits_2::Compare_y_at_x_left_2 `Compare_y_at_x_left_2`\endlink:
+
- \link AosBasicTraits_2::Compare_y_at_x_left_2 `Compare_y_at_x_left_2`\endlink:
- Given two \f$x\f$-monotone curves \f$c_1\f$ and \f$c_2\f$ that
share a common maximal (right) endpoint \f$p\f$, determines whether
\f$c_1\f$ is above or under \f$c_2\f$ immediately to the left of
@@ -3328,7 +3325,7 @@ supports the following predicate:
-If the `ArrangementBasicTraits_2::Has_left_category` type nested in a
+If the `AosBasicTraits_2::Has_left_category` type nested in a
model of the basic concept is defined as `Tag_true`\cgalFootnote{In
principle, the category type may only be convertible to the tag type,
but in practice the category is typically explicitly defined as the
@@ -3347,18 +3344,18 @@ bottom, or top side of the boundary of the parameter space, must be
conveyed by the traits class. This is done through the definition of
four additional nested types, namely
-- \link ArrangementBasicTraits_2::Left_side_category
+
- \link AosBasicTraits_2::Left_side_category
`Left_side_category`\endlink,
-
- \link ArrangementBasicTraits_2::Right_side_category
+
- \link AosBasicTraits_2::Right_side_category
`Right_side_category`\endlink,
-
- \link ArrangementBasicTraits_2::Bottom_side_category
+
- \link AosBasicTraits_2::Bottom_side_category
`Bottom_side_category`\endlink, and
-
- \link ArrangementBasicTraits_2::Top_side_category
+
- \link AosBasicTraits_2::Top_side_category
`Top_side_category`\endlink.
Each of those types must be convertible
to the type `Arr_oblivious_side_tag` for the class to be a model of
-the concept `ArrangementBasicTraits_2`.
+the concept `AosBasicTraits_2`.
\subsubsection aos_sssec-geom_traits-concepts_intersecting Intersections
@@ -3366,17 +3363,17 @@ the concept `ArrangementBasicTraits_2`.
Constructing an arrangement induced by \f$x\f$-monotone curves that
may intersect in their interior requires operations that are not part
-of the `ArrangementBasicTraits_2` concept. The additional operations
-are listed by the concept `ArrangementXMonotoneTraits_2`, which
+of the `AosBasicTraits_2` concept. The additional operations
+are listed by the concept `AosXMonotoneTraits_2`, which
refines the basic arrangement geometry-traits concept described above.
-While models of the `ArrangementXMonotoneTraits_2` concept still
+While models of the `AosXMonotoneTraits_2` concept still
handle only \f$x\f$-monotone curves, the curves are not restricted to
be disjoint in their interiors. Such a model must be capable of
computing points of intersection between \f$x\f$-monotone curves,
splitting curves at these intersection points to obtain pairs of
interior-disjoint subcurves, and optionally merging pairs of
subcurves. A point of intersection between two curves is also
-represented by the \link ArrangementBasicTraits_2::Point_2
+represented by the \link AosBasicTraits_2::Point_2
`Point_2`\endlink type. A model of the refined concept must define an
additional type called `Multiplicity`. An object of this type
indicates the multiplicity of the intersection point of two curves,
@@ -3397,12 +3394,12 @@ operations:
-- \link ArrangementXMonotoneTraits_2::Split_2 `Split_2`\endlink:
+
- \link AosXMonotoneTraits_2::Split_2 `Split_2`\endlink:
- Splits an \f$x\f$-monotone curve \f$c\f$ into two subcurves at a
given point \f$p\f$ that lies in the interior of \f$c\f$.
-
- \link ArrangementXMonotoneTraits_2::Are_mergeable_2 `Are_mergeable_2`\endlink:
-
- Determines whether two \f$ x\f$-monotone curves \f$c_1\f$ and
+
- \link AosXMonotoneTraits_2::Are_mergeable_2 `Are_mergeable_2`\endlink:
+
- Determines whether two \f$x\f$-monotone curves \f$c_1\f$ and
\f$c_2\f$ that share a common endpoint can be merged into a single
continuous \f$x\f$-monotone curve representable by the traits
class.\cgalFootnote{On the face of it this seems a difficult
@@ -3411,10 +3408,10 @@ operations:
underlying curves are identical and whether they do not bend to form
a non-\f$x\f$-monotone curve.}
-
- \link ArrangementXMonotoneTraits_2::Merge_2 `Merge_2`\endlink:
+
- \link AosXMonotoneTraits_2::Merge_2 `Merge_2`\endlink:
- Merges two mergeable \f$x\f$-monotone curves into a single curve.
-
- \link ArrangementXMonotoneTraits_2::Intersect_2 `Intersect_2`\endlink:
+
- \link AosXMonotoneTraits_2::Intersect_2 `Intersect_2`\endlink:
- Computes all intersection points and overlapping sections of two
given \f$x\f$-monotone curves. If possible, computes also the
multiplicity of each intersection point. Providing the multiplicity
@@ -3428,12 +3425,12 @@ operations:
-Using a model of the `ArrangementXMonotoneTraits_2` it is
+Using a model of the `AosXMonotoneTraits_2` it is
possible to construct arrangements of sets of \f$x\f$-monotone curves
(and points) that may intersect one another. The two operations
listed above, regarding the merging of curves, are optional, and should
be provided only if the type `Has_merge_category` nested in a model of
-the `ArrangementXMonotoneTraits_2` concept is defined as `Tag_true`.
+the `AosXMonotoneTraits_2` concept is defined as `Tag_true`.
Otherwise, it is not possible to merge \f$x\f$-monotone curve and
redundant vertices may be left in the arrangement due to the removal of
edges.
@@ -3442,11 +3439,11 @@ edges.
\subsubsection aos_sssec-geom_traits-concepts_arbitrary Supporting Arbitrary Curves
-The concept `ArrangementTraits_2` refines the
-`ArrangementXMonotoneTraits_2` concept. A model of the refined concept
+The concept `AosTraits_2` refines the
+`AosXMonotoneTraits_2` concept. A model of the refined concept
must define an additional type that is used to represent general, not
necessarily \f$x\f$-monotone and not necessarily continuous, curves,
-named \link ArrangementTraits_2::Curve_2 `Curve_2`\endlink. It also
+named \link AosTraits_2::Curve_2 `Curve_2`\endlink. It also
has to support the subdivision of a curve of that type into a set of
continuous \f$x\f$-monotone curves and isolated points. For example,
the curve \f$c:\ (x^2 + y^2)(x^2 + y^2 - 1) = 0\f$ comprises the unit
@@ -3459,20 +3456,20 @@ operation:
-- \link ArrangementTraits_2::Make_x_monotone_2 `Make_x_monotone_2`\endlink:
+
- \link AosTraits_2::Make_x_monotone_2 `Make_x_monotone_2`\endlink:
- Divides a given general curve of type \link
- ArrangementTraits_2::Curve_2 `Curve_2`\endlink into continuous weakly
+ AosTraits_2::Curve_2 `Curve_2`\endlink into continuous weakly
\f$x\f$-monotone curves and isolated points.
-Note that a model of the refined concept `ArrangementTraits_2` is
+Note that a model of the refined concept `AosTraits_2` is
required only when using the free `insert()` function templates (see
Section \ref arr_secgl_funcs) that accept an object of type \link
-ArrangementTraits_2::Curve_2 `Curve_2`\endlink or a range of objects
+AosTraits_2::Curve_2 `Curve_2`\endlink or a range of objects
of that type. In all other cases it is sufficient to use a model of
-the `ArrangementXMonotoneTraits_2` concept.
+the `AosXMonotoneTraits_2` concept.
\subsubsection aos_sssec-tr_landmarks_concept The Landmark Concept
@@ -3489,22 +3486,22 @@ The type of an arrangement associated with the landmark point-location
strategy (see Section \ref arr_ssecpl) must be an instance of the
`Arrangement_on_surface_2` class template,
where the `GeomTraits` parameter is substituted by a model of the
-concept `ArrangementLandmarkTraits_2`. (Naturally, it can also model
-either the `ArrangementXMonotoneTraits_2` concept or the
-`ArrangementTraits_2` concept.) The `ArrangementLandmarkTraits_2`
-concept refines the two concepts `ArrangementApproximateTraits_2` and
-`ArrangementConstructXMonotoneCurveTraits_2`. Each of these two
-concepts, in turn, refines the concept `ArrangementBasicTraits_2`.
+concept `AosLandmarkTraits_2`. (Naturally, it can also model
+either the `AosXMonotoneTraits_2` concept or the
+`AosTraits_2` concept.) The `AosLandmarkTraits_2`
+concept refines the two concepts `AosApproximatePointTraits_2` and
+`AosConstructXMonotoneCurveTraits_2`. Each of these two
+concepts, in turn, refines the concept `AosBasicTraits_2`.
-A model of the `ArrangementApproximateTraits_2` concept must define a
+A model of the `AosApproximatePointTraits_2` concept must define a
fixed precision number type (typically the double-precision
floating-point `double`) and support the operation below (in addition
-to fulfilling the requirements listed by the `ArrangementBasicTraits_2`
+to fulfilling the requirements listed by the `AosBasicTraits_2`
concept).
-- \link ArrangementApproximateTraits_2::Approximate_2 `Approximate_2`\endlink:
+
- \link AosApproximatePointTraits_2::Approximate_2 `Approximate_2`\endlink:
- Given a point `p`, approximate the \f$x\f$ and
\f$y\f$-coordinates of `p` using a not necessarily multi-precision
number type. We use this operation for approximate
@@ -3515,33 +3512,32 @@ fixed-precision number type.
-A model of the `ArrangementConstructXMonotoneCurveTraits_2` concept
+A model of the `AosConstructXMonotoneCurveTraits_2` concept
must support the operation below (in addition to fulfilling the
-requirements listed by the `ArrangementBasicTraits_2` concept).
+requirements listed by the `AosBasicTraits_2` concept).
-- \link ArrangementConstructXMonotoneCurveTraits_2::Construct_x_monotone_curve_2 `Construct_x_monotone_curve_2`\endlink:
+
- \link AosConstructXMonotoneCurveTraits_2::Construct_x_monotone_curve_2 `Construct_x_monotone_curve_2`\endlink:
- Given two points \f$p_1\f$ and \f$p_2\f$, construct
an \f$x\f$-monotone curve connecting \f$p_1\f$ and \f$p_2\f$.
-Most traits classes model the `ArrangementTraits_2` concept, and some
-also model the `ArrangementLandmarkTraits_2` concept.
+Most traits classes model the `AosTraits_2` concept, and some
+also model the `AosLandmarkTraits_2` concept.
+
+The concept `AosConstructCurveTraits_2` refines the concept
+`AosBasicTraits_2`. A model of the `AosConstructCurveTraits_2` concept
+must support the operation below (in addition to fulfilling the
+requirements listed by the `AosBasicTraits_2` concept).
\subsubsection aos_sssec-tr_additional_concepts The Construct Curve Concept
-The concept `ArrangementConstructCurveTraits_2` refines the concept
-`ArrangementTraits_2`. A model of the
-`ArrangementConstructCurveTraits_2` concept must support the operation
-below (in addition to fulfilling the requirements listed by the
-`ArrangementTraits_2` concept).
-
-- \link ArrangementConstructCurveTraits_2::Construct_curve_2 `Construct_curve_2`\endlink:
+
- \link AosConstructCurveTraits_2::Construct_curve_2 `Construct_curve_2`\endlink:
- Given two points \f$p_1\f$ and \f$p_2\f$, construct
a curve connecting \f$p_1\f$ and \f$p_2\f$.
@@ -3550,9 +3546,62 @@ The `Arr_polyline_traits_2` class template handles
polylines; see Section ~\ref arr_sssectr_polylines.
The type that substitutes the template parameter `SubcurveTraits_2`
when `Arr_polyline_traits_2` is instantiated must be
-a geometry-traits class that models the concept `ArrangementConstructCurveTraits_2`
+a geometry-traits class that models the concept `AosConstructCurveTraits_2`
to enable the construction of polylines from a sequence of two or more points.
+
+\subsubsection aos_sssec-tr_approximatetion_concept Supporting Approximations of Curves
+
+
+Operations on arrangements are guaranteed to be robust only if the
+operations of the geometry traits used to carry out the high-level
+operations are robust. Geometry traits constructors are guaranteed to
+be robust only if the kernel in use supports exact constructions, such
+as the Epec kernel. Even if you only intend to perform point-location
+queries on an arrangement induced by a collection of curves, you need
+an exact-construction kernel, if the curves are not pairwise disjoint
+in their interiors. However, when using an exact-construction kernel
+you still may desire to perform (independent) operations on
+approximations of the points or the interior-disjoint \f$x\f$-monotone
+curves of the arrangements in order to gain speed, for example drawing
+the arrangement on a raster window. Naturally, reconstructing an
+arrangement from the approximations of its points and
+interior-disjoint \f$x\f$-monotone curves, may result with an arrangement
+of a different topology, or even worse, intersections in the interior
+of the curves.
+
+The concept `AosApproximateTraits_2` refines the concept
+`AosApproximatePointTraits_2`. In addition to the type
+`Approximate_number_type` required by the latter, a model of the
+`AosApproximateTraits_2` concept must define the type
+`Approximate_point_2`, which is typically defined as
+`CGAL::Cartesian::%Point_2`. Also, it must
+support the operations below (in addition to the operation required by
+the concept `AosApproximatePointTraits_2`).
+
+
+- \link AosApproximateTraits_2::Approximate_2 `Approximate_2`\endlink:
+
- This operation is overloaded with three versions. The first one
+ returns an approximation of the \f$x\f$- or \f$y\f$-coordinates of a given
+ point as required by the concept `AosApproximatePointTraits_2`; see
+ Section \ref aos_sssec-tr_landmarks_concept. The description of the remaining
+ two follow.
+
+ (i) Given a point \f$p\f$, obtain an approximation of \f$p\f$, which is an
+ object of type `Approximate_point_2`. This is trivially
+ implemented using the first version.
+
+ (ii) Given an \f$x\f$-monotone curve \f$c\f$, a small number \f$\epsilon\f$ of
+ type `Approximate_number_type` that serves as an error bound, an
+ output iterator associated with a container
+ of approximate points, and a flag that indicates whether to
+ approximate \f$c\f$ starting from its smallest lexicographic endpoint,
+ compute a polyline that approximates \f$c\f$ in the indicated
+ direction, such that the largest distance between \f$c\f$ and the
+ polyline is not larger than \f$\epsilon\f$. The polyline is
+ represented as a sequence of approximate points.
+
+
\subsubsection aos_ssec-traits-curved Supporting Unbounded Curves or Curved Surfaces
@@ -3567,13 +3616,13 @@ boundary sides) or approach them (the pre-images of their endpoints
approach boundary sides). These boundary conditions typically occur
with unbounded curves or with arrangements embedded in curved
surfaces. The category types \link
-ArrangementBasicTraits_2::Left_side_category
+AosBasicTraits_2::Left_side_category
`Left_side_category`\endlink, \link
-ArrangementBasicTraits_2::Right_side_category
+AosBasicTraits_2::Right_side_category
`Right_side_category`\endlink, \link
-ArrangementBasicTraits_2::Bottom_side_category
+AosBasicTraits_2::Bottom_side_category
`Bottom_side_category`\endlink, and \link
-ArrangementBasicTraits_2::Top_side_category
+AosBasicTraits_2::Top_side_category
`Top_side_category`\endlink, nested in every geometry traits class
indicate whether the corresponding boundary side (i.e., left, right,
bottom, and top) is open, closed, contracted, or identified, and
@@ -3602,9 +3651,9 @@ closed, contracted, and identified sides, respectively. (When curves
are expected to neither reach nor approach a particular side, special
handling is not required; thus, there is no need for a corresponding
concept.) For example, it is required that the category type \link
-ArrangementOpenBottomTraits_2::Bottom_side_category
+AosOpenBottomTraits_2::Bottom_side_category
`Bottom_side_category`\endlink, nested in models of the concept
-`ArrangementOpenBottomTraits_2`, is convertible to the tag type
+`AosOpenBottomTraits_2`, is convertible to the tag type
`Arr_open_side_tag`. This makes for a total of 16 abstract concepts
(combine one of left, right, bottom, and top with one of open, closed,
contracted, identified). Any one of these individual abstract concept
@@ -3618,8 +3667,8 @@ contracted side must be adjacent to two identified sides. While this
narrows down the number of tangible concepts, the total number is
still high; in practice we have used only two so far (not counting the
"plain" concept, models of which do not handle boundary conditions at
-all), namely, `ArrangementOpenBoundaryTraits_2` and
-`ArrangementSphericalBoundaryTraits_2`; see below for more
+all), namely, `AosOpenBoundaryTraits_2` and
+`AosSphericalBoundaryTraits_2`; see below for more
details. Many of the traits class-templates provided by the \ref
PkgArrangementOnSurface2 package do not handle boundary conditions at
all. Some of them, such as the `Arr_segment_traits_2` traits (see
@@ -3641,7 +3690,7 @@ sufficient to handle not only curves embedded in an unbounded
parameter space, but also curves embedded in a bounded parameter space
with open boundaries. The arrangement type instantiated with a traits
class that models the combined concept
-`ArrangementOpenBoundaryTraits_2` shown in
+`AosOpenBoundaryTraits_2` shown in
\cgalFigureRef{aos_fig-open_concept_hierarchy} can handle curves that
are open in any direction. Recall that an arrangement that supports
unbounded \f$x\f$-monotone curves maintains an implicit bounding
@@ -3651,20 +3700,21 @@ are expected to be unbounded; namely, there exists \f$d \in \{0,1\}\f$
such that \f$\lim_{t \rightarrow d}x(t) = \pm\infty\f$ or \f$\lim_{t
\rightarrow d}y(t) = \pm\infty\f$ holds for at least one input curve
\f$c(t) = (x(t),y(t))\f$, the arrangement template must be
-instantiated with a model of the `ArrangementOpenBoundaryTraits_2`
+instantiated with a model of the `AosOpenBoundaryTraits_2`
concept.\cgalFootnote{A curve that reaches the boundary of the
parameter space in this case is open and unbounded.}
\cgalFigureBegin{aos_fig-spherical_concept_hierarchy,spherical_concept_hierarchy.png}
-Bottom portion of the refinement hierarchy of the geometry-traits
-concepts for curves embedded in a sphere-like parameterized surface
+The entire spherical boundary cluster of the refinement hierarchy of the
+geometry-traits concepts for curves embedded in a sphere-like parameterized
+surface.
\cgalFigureEnd
A suitable geometry-traits component for arrangements embedded in
surfaces homeomorphic to a sphere is a model of the combined concept
-`ArrangementSphericalBoundaryTraits_2` shown in
+`AosSphericalBoundaryTraits_2` shown in
\cgalFigureRef{aos_fig-spherical_concept_hierarchy}. Here the two
vertical sides of the parameter space are identified and the two
horizontal sides are contracted.
@@ -3679,9 +3729,9 @@ exists for the right, bottom, and top sides.
The shared requirements for the four options of a side are collected
-in abstract layers called `ArrangementLeftSideTraits_2`,
-`ArrangementRightSideTraits_2`, `ArrangementBottomSideTraits_2`, and
-`ArrangementTopSideTraits_2`; see, e.g.,
+in abstract layers called `AosLeftSideTraits_2`,
+`AosRightSideTraits_2`, `AosBottomSideTraits_2`, and
+`AosTopSideTraits_2`; see, e.g.,
\cgalFigureRef{aos_fig-left_side_cluster}.
@@ -3695,8 +3745,8 @@ curves that either reach or approach horizontal sides.
The shared requirements for the options of opposite sides are
collected in two additional abstract layers called
-`ArrangementVerticalSideTraits_2` and
-`ArrangementHorizontalSideTraits_2`; see
+`AosVerticalSideTraits_2` and
+`AosHorizontalSideTraits_2`; see
\cgalFigureRef{aos_fig-side_clusters}.
@@ -3717,8 +3767,8 @@ of the parameter space and for curves that reach the identified top
side of the parameter space do not exist either. Instead, the shared
requirements for opposite identified sides are collected in two
additional abstract concepts called
-`ArrangementIdentifiedVerticalTraits_2` and
-`ArrangementIdentifiedHorizontalTraits_2`; see
+`AosIdentifiedVerticalTraits_2` and
+`AosIdentifiedHorizontalTraits_2`; see
\cgalFigureRef{aos_fig-identified_clusters}. The former lists
requirements for operations that handle curves that reach identified
vertical sides of the parameter space, and the latter lists
@@ -3728,12 +3778,12 @@ horizontal sides of the parameter space.
In the following we list the specific requirements of all the
aforementioned concepts.
-The abstract concept `ArrangementVerticalSideTraits_2` requires the
+The abstract concept `AosVerticalSideTraits_2` requires the
following predicate:
-- \link ArrangementVerticalSideTraits_2::Parameter_space_in_x_2 `Parameter_space_in_x_2`\endlink:
+
- \link AosVerticalSideTraits_2::Parameter_space_in_x_2 `Parameter_space_in_x_2`\endlink:
- This three-valued predicate is overloaded with two versions as
follows:
@@ -3763,18 +3813,18 @@ in between. Return `CGAL::ARR_LEFT_BOUNDARY`,
min},x_{\rm max}\}\f$, then the boundary side containing \f$p\f$
cannot be open and must not be identified. In other words, this
overloaded version is required only for the concepts
-`ArrangementClosedLeftTraits_2`, `ArrangementClosedRightTraits_2`,
-`ArrangementContractedLeftTraits_2` and
-`ArrangementContractedRightTraits_2`.
+`AosClosedLeftTraits_2`, `AosClosedRightTraits_2`,
+`AosContractedLeftTraits_2` and
+`AosContractedRightTraits_2`.
-The abstract concept `ArrangementHorizontalSideTraits_2` requires the
+The abstract concept `AosHorizontalSideTraits_2` requires the
following predicate:
-- \link ArrangementHorizontalSideTraits_2::Parameter_space_in_y_2 `Parameter_space_in_y_2`\endlink:
+
- \link AosHorizontalSideTraits_2::Parameter_space_in_y_2 `Parameter_space_in_y_2`\endlink:
- This three-valued predicate is overloaded with two versions as
follows:
@@ -3804,9 +3854,9 @@ in between. Return `CGAL::ARR_BOTTOM_BOUNDARY`,
min},y_{\rm max}\}\f$, then the boundary side containing \f$p\f$
cannot be open and must not be identified. In other words, this
overloaded version is required only for the concepts
-`ArrangementClosedBottomTraits_2`, `ArrangementClosedTopTraits_2`,
-`ArrangementContractedBottomTraits_2` and
-`ArrangementContractedTopTraits_2`.
+`AosClosedBottomTraits_2`, `AosClosedTopTraits_2`,
+`AosContractedBottomTraits_2` and
+`AosContractedTopTraits_2`.
@@ -3823,14 +3873,14 @@ asymmetry is also reflected in the predicates listed below. They help
determining the order of curve-ends lying on the boundary of the
parameter space with respect to regular points and among each other.
-The concepts `ArrangementClosedLeftTraits_2`,
-`ArrangementClosedRightTraits_2`, and
-`ArrangementIdentifiedVerticalTraits_2` require the following
+The concepts `AosClosedLeftTraits_2`,
+`AosClosedRightTraits_2`, and
+`AosIdentifiedVerticalTraits_2` require the following
additional predicate:
-- \link ArrangementIdentifiedVerticalTraits_2::Compare_y_on_boundary_2 `Compare_y_on_boundary_2`\endlink:
+
- \link AosIdentifiedVerticalTraits_2::Compare_y_on_boundary_2 `Compare_y_on_boundary_2`\endlink:
- Given two points \f$p_1=(x_{p_1},y_{p_1})\f$ and
\f$p_2=(x_{p_2},y_{p_2})\f$, such that at least one of them lies on a
@@ -3841,16 +3891,16 @@ min},x_{\rm max}\}\f$ (resp. \f$x_{p_2} \in \{x_{\rm min},x_{\rm
max}\}\f$), then the vertical boundary side containing \f$p_1\f$
(resp. \f$p_2\f$) must be either closed or identified. In other words,
this overloaded version is required only for the concepts
-`ArrangementClosedLeftTraits_2`, `ArrangementClosedRightTraits_2`, and
-`ArrangementIdentifiedVerticalTraits_2`.
+`AosClosedLeftTraits_2`, `AosClosedRightTraits_2`, and
+`AosIdentifiedVerticalTraits_2`.
-The concept `ArrangementVerticalSideTraits_2` requires the following additional predicate:
+The concept `AosVerticalSideTraits_2` requires the following additional predicate:
-- \link ArrangementVerticalSideTraits_2::Compare_y_near_boundary_2 `Compare_y_near_boundary_2`\endlink:
+
- \link AosVerticalSideTraits_2::Compare_y_near_boundary_2 `Compare_y_near_boundary_2`\endlink:
-
@@ -3882,12 +3932,12 @@ boundary-side in a similar manner.
-The concept `ArrangementHorizontalSideTraits_2` requires two additional
+The concept `AosHorizontalSideTraits_2` requires two additional
predicates:
-- \link ArrangementHorizontalSideTraits_2::Compare_x_on_boundary_2 `Compare_x_on_boundary_2`\endlink:
+
- \link AosHorizontalSideTraits_2::Compare_x_on_boundary_2 `Compare_x_on_boundary_2`\endlink:
- This predicate is overloaded with three versions.
We distinguish between open and non-open sides as explained below.
@@ -3941,10 +3991,10 @@ min},y_{\rm max}\}\f$ (resp. \f$y_{p_2} \in \{y_{\rm min},y_{\rm
max}\}\f$), then the boundary side containing \f$p_1\f$
(resp. \f$p_2\f$) must be either closed or identified. In other words,
this overloaded version is required only for the concepts
-`ArrangementClosedBottomTraits_2`, `ArrangementClosedTopTraits_2`,
-and `ArrangementIdentifiedHorizontalTraits_2`.
+`AosClosedBottomTraits_2`, `AosClosedTopTraits_2`,
+and `AosIdentifiedHorizontalTraits_2`.
-
- \link ArrangementHorizontalSideTraits_2::Compare_x_near_boundary_2
+
- \link AosHorizontalSideTraits_2::Compare_x_near_boundary_2
`Compare_x_near_boundary_2`\endlink:
-
@@ -3981,12 +4031,12 @@ boundary-side, \f$p\f$ is located far to the top in a similar manner.
-The concept `ArrangementIdentifiedVerticalTraits_2` requires the following
+The concept `AosIdentifiedVerticalTraits_2` requires the following
additional predicate:
-- \link ArrangementIdentifiedVerticalTraits_2::Is_on_y_identification_2 `Is_on_y_identification_2`\endlink:
+
- \link AosIdentifiedVerticalTraits_2::Is_on_y_identification_2 `Is_on_y_identification_2`\endlink:
- This predicate is overloaded with two versions.
@@ -4001,12 +4051,12 @@ boundary.
-Similarly, the concept `ArrangementIdentifiedHorizontalTraits_2`
+Similarly, the concept `AosIdentifiedHorizontalTraits_2`
requires the following additional predicate:
-- \link ArrangementIdentifiedHorizontalTraits_2::Is_on_x_identification_2 `Is_on_x_identification_2`\endlink:
+
- \link AosIdentifiedHorizontalTraits_2::Is_on_x_identification_2 `Is_on_x_identification_2`\endlink:
- This predicate is overloaded with two versions.
@@ -4143,14 +4193,14 @@ template that handles line segments, namely the
`Arr_non_caching_segment_basic_traits_2` class template. This
class template and the `Arr_segment_traits_2` class template
are both parameterized by a geometric kernel and model the concepts
-`ArrangementTraits_2` and `ArrangementLandmarkTraits_2`.
+`AosTraits_2` and `AosLandmarkTraits_2`.
\cgalFootnote{They also model the refined concept
-\cgalFootnoteCode{ArrangementDirectionalXMonotoneTraits_2}, which enables Boolean set
+\cgalFootnoteCode{AosDirectionalXMonotoneTraits_2}, which enables Boolean set
operations; see Package \ref PkgBooleanSetOperations2Ref.} The class
template `Arr_non_caching_segment_traits_2` derives from the
instance `Arr_non_caching_segment_basic_traits_2`, which
-models the `ArrangementLandmarkTraits_2` traits concept but not the
-refined `ArrangementXMonotoneTraits_2` concept. Like the
+models the `AosLandmarkTraits_2` traits concept but not the
+refined `AosXMonotoneTraits_2` concept. Like the
`Arr_segment_traits_2` class template it derives from the `Kernel`
type. Unlike the `Arr_segment_traits_2` class template it defines its
point and segment types as `Kernel::Point_2` and `Kernel::Segment_2`,
@@ -4197,8 +4247,8 @@ The `Arr_linear_traits_2` class used in Section \ref
aos_sec-unbounded for demonstrating the construction of arrangements
of unbounded curves is capable of handling bounded and unbounded
linear objects, namely, lines, rays, and line segments. It models the
-concepts `ArrangementTraits_2`, `ArrangementLandmarkTraits_2`, and
-`{ArrangementOpenBoundaryTraits_2`. It is parameterized by a geometric
+concepts `AosTraits_2`, `AosLandmarkTraits_2`, and
+`{AosOpenBoundaryTraits_2`. It is parameterized by a geometric
kernel and its nested \link Arr_linear_traits_2::Point_2
`Point_2`\endlink type is defined to be the kernel-point type. The
\link Arr_linear_traits_2::Curve_2 `Curve_2`\endlink (and \link
@@ -4242,13 +4292,13 @@ arr_sssectr_polycurves.
The `Arr_polyline_traits_2` class template handles
polylines. It models the following four concepts:
-- `ArrangementTraits_2`,
+- `AosTraits_2`,
-- `ArrangementDirectionalXMonotoneTraits_2`
+- `AosDirectionalXMonotoneTraits_2`
-- `ArrangementConstructXMonotoneCurveTraits_2`, and
+- `AosConstructXMonotoneCurveTraits_2`, and
-- `ArrangementConstructCurveTraits_2`.
+- `AosConstructCurveTraits_2`.
The type that substitutes the template parameter `SubcurveTraits_2`
when `Arr_polyline_traits_2` is instantiated must be
@@ -4256,16 +4306,16 @@ a geometry-traits class that models the same four concepts. We refer
to the type that substitutes the template parameter `SubcurveTraits_2`
as the subcurve traits hereafter. If, in addition, the
subcurve traits also models the concept
-`ArrangementApproximateTraits_2` then the instantiated
+`AosApproximatePointTraits_2` then the instantiated
`Arr_polyline_traits_2` type models the concept
-`ArrangementApproximateTraits_2` as well. (By definition, modeling the
-concepts `ArrangementApproximateTraits_2` and
-`ArrangementConstructXMonotoneCurveTraits_2` implies modeling the
-concept `ArrangementLandmarkTraits_2`.) Similarly, if the subcurve
-traits also models the concept `ArrangementOpenBoundaryTraits_2` then
+`AosApproximatePointTraits_2` as well. (By definition, modeling the
+concepts `AosApproximatePointTraits_2` and
+`AosConstructXMonotoneCurveTraits_2` implies modeling the
+concept `AosLandmarkTraits_2`.) Similarly, if the subcurve
+traits also models the concept `AosOpenBoundaryTraits_2` then
the instantiated `Arr_polyline_traits_2` type models
-the concept `ArrangementOpenBoundaryTraits_2` as well. Modeling the
-`ArrangementConstructXMonotoneCurveTraits_2` concept implies that the
+the concept `AosOpenBoundaryTraits_2` as well. Modeling the
+`AosConstructXMonotoneCurveTraits_2` concept implies that the
subcurve traits must support the construction of a unique
(\f$x\f$-monotone) segment given two input points.
@@ -4403,14 +4453,14 @@ template, instantiated with the predefined filtered kernel.
#include
#include
-typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
-typedef Kernel::FT Number_type;
+using Kernel = CGAL::Exact_predicates_exact_constructions_kernel;
+using Number_type = Kernel::FT;
-typedef CGAL::Arr_segment_traits_2 Segment_traits;
-typedef CGAL::Arr_polyline_traits_2 Traits;
-typedef Traits::Point_2 Point;
-typedef Traits::Curve_2 Polyline;
-typedef CGAL::Arrangement_2 Arrangement;
+using Segment_traits = CGAL::Arr_segment_traits_2;
+using Traits = CGAL::Arr_polyline_traits_2;
+using Point = Traits::Point_2;
+using Polyline = Traits::Curve_2;
+using Arrangement = CGAL::Arrangement_2;
\endcode
@@ -4428,8 +4478,8 @@ is continuous. As a matter of fact, most characteristics of the
also to the `Arr_polycurve_traits_2` traits class
template. The only difference between the two, is that the latter is
not a model of the concepts
-`ArrangementConstructXMonotoneCurveTraits_2` nor
-`ArrangementConstructCurveTraits_2`, and as such, it is not
+`AosConstructXMonotoneCurveTraits_2` nor
+`AosConstructCurveTraits_2`, and as such, it is not
able to construct a subcurve from only two points. As a consequence,
it does not support the operations that (i) construct a polycurve from
a sequence of points, and (ii) push a point at the back or at the
@@ -4538,10 +4588,10 @@ are rational).
The \ref PkgArrangementOnSurface2 package offers a traits
class-template called `Arr_circle_segment_traits_2` that
exclusively handles line segments, circular arcs, and whole circles
-and models the concepts `ArrangementTraits_2` and
-`ArrangementDirectionalXMonotoneTraits_2`; see Package \ref
+and models the concepts `AosTraits_2` and
+`AosDirectionalXMonotoneTraits_2`; see Package \ref
PkgBooleanSetOperations2Ref. Note that it is not a model of the
-`ArrangementLandmarkTraits_2` concept. It exploits efficient
+`AosLandmarkTraits_2` concept. It exploits efficient
computations with square root numbers, which makes it attractive for
arrangements induced by line segments, circular arcs, and whole
circles. When the traits class-template is instantiated, the `Kernel`
@@ -4592,16 +4642,16 @@ performance further.
#include
#include
-typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
-typedef Kernel::FT Number_type;
-typedef CGAL::Arr_circle_segment_traits_2 Traits;
-typedef Traits::CoordNT CoordNT;
-typedef Traits::Point_2 Point;
-typedef Traits::Curve_2 Curve;
-typedef Traits::Rational_point_2 Rational_point;
-typedef Traits::Rational_segment_2 Segment;
-typedef Traits::Rational_circle_2 Circle;
-typedef CGAL::Arrangement_2 Arrangement;
+using Kernel = CGAL::Exact_predicates_exact_constructions_kernel;
+using Number_type = Kernel::FT;
+using Traits = CGAL::Arr_circle_segment_traits_2;
+using CoordNT = Traits::CoordNT;
+using Point = Traits::Point_2;
+using Curve = Traits::Curve_2;
+using Rational_point = Traits::Rational_point_2;
+using Segment = Traits::Rational_segment_2;
+using Circle = Traits::Rational_circle_2;
+using Arrangement = CGAL::Arrangement_2;
\endcode
The \link Arr_circle_segment_traits_2::Curve_2 `Curve_2`\endlink type
@@ -4763,8 +4813,8 @@ type traits-class, then use them to define the conic traits
class-template. Also note the types defined by the rational kernels,
which we need for conveniently constructing conic arcs.
-The `Arr_conic_traits_2` models the `ArrangementTraits_2` and
-`ArrangementLandmarkTraits_2` concepts. Its \link
+The `Arr_conic_traits_2` models the `AosTraits_2` and
+`AosLandmarkTraits_2` concepts. Its \link
Arr_conic_traits_2::Point_2 `Point_2`\endlink type is derived from
`AlgKernel::Point_2`, while the \link Arr_conic_traits_2::Curve_2
`Curve_2`\endlink type represents a bounded, not necessarily
@@ -4867,7 +4917,7 @@ they have another intersection point at
A rational function is given by the equation \f$y =
\frac{P(x)}{Q(x)}\f$, where \f$P\f$ and \f$Q\f$ are polynomials of
-arbitrary degrees. In particular, if \f$ Q(x) = 1\f$, then the
+arbitrary degrees. In particular, if \f$Q(x) = 1\f$, then the
function is simply a polynomial function. A bounded rational
arc is defined by the graph of a rational function over some
interval \f$[x_{\rm min}, x_{\rm max}]\f$, where \f$Q\f$ does not have
@@ -4883,12 +4933,12 @@ more complicated curves and for interpolation; see, e.g.,
Using the `Arr_rational_function_traits_2` class template it is
possible to construct and maintain arrangements induced by rational
arcs. Every instance of the `Arr_rational_function_traits_2` class
-template models the concepts `ArrangementTraits_2` and
-`ArrangementOpenBoundaryTraits_2`, but it does not model the
-`ArrangementLandmarkTraits_2` concept. It also models the refined
-concept `ArrangementDirectionalXMonotoneTraits_2`, which enables
+template models the concepts `AosTraits_2` and
+`AosOpenBoundaryTraits_2`, but it does not model the
+`AosLandmarkTraits_2` concept. It also models the refined
+concept `AosDirectionalXMonotoneTraits_2`, which enables
Boolean set operations; see Package \ref PkgBooleanSetOperations2Ref.
-Note that it is not a model of `ArrangementLandmarkTraits_2` concept,
+Note that it is not a model of `AosLandmarkTraits_2` concept,
so it is impossible to use the landmark point-location strategy with
this traits class.
@@ -4909,7 +4959,7 @@ depicted in \cgalFigureRef{aos_fig-rat_func_singular}. This arc has
two singularities, at \f$x = 1\f$ and at \f$x = 2\f$. It is split into
three continuous portions defined over the intervals \f$[0,1)\f$,
\f$(1,2)\f$, and \f$(2,3]\f$ by the traits operation \link
-ArrangementTraits_2::Make_x_monotone_2
+AosTraits_2::Make_x_monotone_2
`Make_x_monotone_2`\endlink. Arbitrary rational functions are
represented by the nested type \link
Arr_rational_function_traits_2::Curve_2 `Curve_2`\endlink and
@@ -4968,15 +5018,15 @@ are defined in the header file `arr_rat_functions.h`.
#include
#include
-typedef CORE::BigInt Number_type;
-typedef CGAL::Algebraic_kernel_d_1 AK1;
-typedef CGAL::Arr_rational_function_traits_2 Traits;
+using Number_type = CORE::BigInt;
+using AK1 = CGAL::Algebraic_kernel_d_1;
+using Traits = CGAL::Arr_rational_function_traits_2;
-typedef Traits::Polynomial_1 Polynomial;
-typedef Traits::Algebraic_real_1 Alg_real;
-typedef Traits::Bound Bound;
+using Polynomial = Traits::Polynomial_1;
+using Alg_real = Traits::Algebraic_real_1;
+using Bound = Traits::Bound;
-typedef CGAL::Arrangement_2 Arrangement;
+using Arrangement = CGAL::Arrangement_2;
\endcode
The constructed rational functions are cached by the traits class. The
@@ -5082,17 +5132,17 @@ header file `arr_Bezier.h`.
#include
#include
-typedef CGAL::CORE_algebraic_number_traits Nt_traits;
-typedef Nt_traits::Rational NT;
-typedef Nt_traits::Rational Rational;
-typedef Nt_traits::Algebraic Algebraic;
-typedef CGAL::Cartesian Rat_kernel;
-typedef CGAL::Cartesian Alg_kernel;
-typedef Rat_kernel::Point_2 Rat_point;
-typedef CGAL::Arr_Bezier_curve_traits_2
- Traits;
-typedef Traits::Curve_2 Bezier_curve;
-typedef CGAL::Arrangement_2 Arrangement;
+using Nt_traits = CGAL::CORE_algebraic_number_traits;
+using NT = Nt_traits::Rational;
+using Rational = Nt_traits::Rational;
+using Algebraic = Nt_traits::Algebraic;
+using Rat_kernel = CGAL::Cartesian;
+using Alg_kernel = CGAL::Cartesian;
+using Rat_point = Rat_kernel::Point_2;
+using Traits =
+ CGAL::Arr_Bezier_curve_traits_2;
+using Bezier_curve = Traits::Curve_2;
+using Arrangement = CGAL::Arrangement_2;
\endcode
As mentioned above, we assume that the coordinates of all control
@@ -5114,9 +5164,9 @@ Arr_Bezier_curve_traits_2::X_monotone_curve_2
`X_monotone_curve_2`\endlink types defined by the traits class.
Every instance of the `Arr_Bezier_curve_traits_2` class templates
-models the concept `ArrangementTraits_2` (but it does not model the
-`ArrangementLandmarkTraits_2` concept). It also models the refined
-concept `ArrangementDirectionalXMonotoneTraits_2`, which enables
+models the concept `AosTraits_2` (but it does not model the
+`AosLandmarkTraits_2` concept). It also models the refined
+concept `AosDirectionalXMonotoneTraits_2`, which enables
Boolean set operations; see Package \ref PkgBooleanSetOperations2Ref.
@@ -5171,9 +5221,9 @@ either vertical or a closed connected point set, with all interior
points parameterizable in \f$x\f$.
Every instance of the `Arr_algebraic_segment_traits_2`
-class template models the `ArrangementTraits_2` and
-`ArrangementOpenBoundaryTraits_2` concepts (but it does not model the
-`ArrangementLandmarkTraits_2` concept). The template argument
+class template models the `AosTraits_2` and
+`AosOpenBoundaryTraits_2` concepts (but it does not model the
+`AosLandmarkTraits_2` concept). The template argument
`Coefficient` determines the type of the scalar coefficients of the
polynomial. Currently supported integral number types are `Gmpz`,
`leda_integer`, and `CORE::BigInt`. This is reflected in the
@@ -5241,12 +5291,12 @@ A weakly \f$x\f$-monotone segment of an algebraic curve is represented
by the \link Arr_algebraic_segment_traits_2::X_monotone_curve_2
`X_monotone_curve_2`\endlink type nested in the traits
class-template. You can construct such segments in two ways as
-follows: (i) using the \link ArrangementTraits_2::Make_x_monotone_2
+follows: (i) using the \link AosTraits_2::Make_x_monotone_2
`Make_x_monotone_2`\endlink functor or (ii) using the \link
Arr_algebraic_segment_traits_2::Construct_x_monotone_segment_2
`Construct_x_monotone_segment_2`\endlink functor. Both functors are
nested in the traits class-template. The former is required by the
-concept `ArrangementTraits_2` our traits class models; see Section
+concept `AosTraits_2` our traits class models; see Section
\ref aos_sssec-geom_traits-concepts_arbitrary. The latter enables the
construction of individual segments. The \link
Arr_algebraic_segment_traits_2::X_monotone_curve_2
@@ -5380,7 +5430,7 @@ segments in Euclidean geometry.
The `Arr_geodesic_arc_on_sphere_traits_2` class template
handles arcs of great circles (also known as geodesic arcs) of a unit
sphere (centered at the origin in \f$\mathbb{R}^3\f$). It is a model of the
-concept `ArrangementSphericalBoundaryTraits_2`; see Section \ref
+concept `AosSphericalBoundaryTraits_2`; see Section \ref
aos_ssec-traits-curved. An arrangement type (an instance of the
template `Arrangement_on_surface_2`) that
uses an instance of this traits class as the geometry traits must use
@@ -5521,8 +5571,8 @@ nested types are defined as follows:
CopyConstructible, EqualityComparable, and DefaultConstructible.
The latter ensures that every instance of the class template
`Arr_curve_data_traits_2` obtained by substituting the `BaseTraits`
- template parameter with a model of the `ArrangementLandmarkTraits_2`
- concept models the `ArrangementLandmarkTraits_2` concept as well
+ template parameter with a model of the `AosLandmarkTraits_2`
+ concept models the `AosLandmarkTraits_2` concept as well
@@ -5670,7 +5720,7 @@ program. The tracing traits supports filtering of traced functors. The
calls `traits.enable_trace(id)` and `traits.disable_trace(id)` enables
and disables the tracing of a functor identified by `id`,
respectively. A functor is identified by an enumeration. For example,
-the functor \link ArrangementTraits_2::Make_x_monotone_2
+the functor \link AosTraits_2::Make_x_monotone_2
`Make_x_monotone_2`\endlink is identified by the enumeration
`Arr_tracing_traits_2::MAKE_X_MONOTONE_OP`. The calls
`traits.enable_all_traces()` and `traits.disable_all_traces()` enables
@@ -5688,7 +5738,7 @@ topological entities and the implementation of the functions that
handle these topological entities, used by the
`Arrangement_on_surface_2` class
template and by the peripheral modules. Every topology traits class
-must model the basic concept `ArrangementBasicTopologyTraits`. A model
+must model the basic concept `AosBasicTopologyTraits`. A model
of this basic concept holds the (\dcel) data structure used to
represent the arrangement cells (i.e., vertices, edges, and facets)
and the incidence relations between them. At this point we do not
@@ -6032,8 +6082,8 @@ In such cases you may explicitly extend the base \dcel
class-template, as described in the next paragraph, or implement your
own \dcel class from scratch and use the resulting \dcel to
instantiate the `Arrangement_2` class template. In any case such a
-class must model the concept `ArrangementDcel` or its refinement
-`ArrangementDcelWithRebind`. The latter requires a `rebind` struct
+class must model the concept `AosDcel` or its refinement
+`AosDcelWithRebind`. The latter requires a `rebind` struct
template, which implements a policy-clone idiom. Here, the \dcel
class is the policy class and the `rebind` member template struct
is used to pass a different traits type parameter to the policy class
@@ -6348,17 +6398,16 @@ header file `Overlay_color_traits.h`.
\code{.cpp}
template struct Overlay_color_traits {
- typedef unsigned int Color;
- typedef typename Arrangement::Vertex_const_handle V_const_handle;
- typedef typename Arrangement::Halfedge_const_handle H_const_handle;
- typedef typename Arrangement::Face_const_handle F_const_handle;
- typedef typename Arrangement::Vertex_handle V_handle;
- typedef typename Arrangement::Halfedge_handle H_handle;
- typedef typename Arrangement::Face_handle F_handle;
+ using Color = unsigned int;
+ using V_const_handle = typename Arrangement::Vertex_const_handle;
+ using H_const_handle = typename Arrangement::Halfedge_const_handle;
+ using F_const_handle = typename Arrangement::Face_const_handle;
+ using V_handle = typename Arrangement::Vertex_handle;
+ using H_handle = typename Arrangement::Halfedge_handle;
+ using F_handle = typename Arrangement::Face_handle;
// Compute the average of the red, green, and blue components separately.
- Color blend(Color color1, Color color2) const
- {
+ Color blend(Color color1, Color color2) const {
return
((((color1 & 0x000000ff) + (color2 & 0x000000ff)) / 2) & 0x000000ff) |
((((color1 & 0x0000ff00) + (color2 & 0x0000ff00)) / 2) & 0x0000ff00) |
@@ -6447,12 +6496,12 @@ between these curves and the arrangement edges they induce. Similarly,
the `Arrangement_with_history_2` class-template
extends the `Arrangement_2` class template. The
`GeometryTraits` template parameter, of either class templates, must
-be substituted by a model of the `ArrangementTraits_2` concept; see
+be substituted by a model of the `AosTraits_2` concept; see
Section \ref aos_ssec-insert_gen. It should define the \link
-ArrangementTraits_2::Curve_2 `Curve_2`\endlink type and support its
-subdivision into \link ArrangementBasicTraits_2::X_monotone_curve_2
+AosTraits_2::Curve_2 `Curve_2`\endlink type and support its
+subdivision into \link AosBasicTraits_2::X_monotone_curve_2
`X_monotone_curve_2`\endlink objects, among the others. The `Dcel`
-parameter must be substituted by a model of the `ArrangementDcel`
+parameter must be substituted by a model of the `AosDcel`
concept. You can use either the default \dcel class or an extended
\dcel class (see Section \ref arr_ssecex_dcel) based on your needs. An
arrangement that support the cross-mapping mentioned above is referred
@@ -6687,8 +6736,8 @@ predefined \ascii format that encodes the arrangement topology, as well
as all geometric entities associated with vertices and edges.
The ability to use the input/output operators, requires that the \link
-ArrangementBasicTraits_2::Point_2 `Point_2`\endlink type and the \link
-ArrangementBasicTraits_2::X_monotone_curve_2
+AosBasicTraits_2::Point_2 `Point_2`\endlink type and the \link
+AosBasicTraits_2::X_monotone_curve_2
`X_monotone_curve_2`\endlink type defined by the traits class both
support the `<<` and `>>` operators. The `Arr_conic_traits_2` class
(see Section \ref arr_sssectr_conic), the
@@ -6755,7 +6804,7 @@ from a file:
\cgalExample{Arrangement_on_surface_2/dcel_extension_io.cpp}
You may develop your own formatter classes - models of the
-`ArrangementInputFormatter` and `ArrangementOutputFormatter`
+`AosInputFormatter` and `AosOutputFormatter`
concepts, as defined in the Reference Manual.
Doing so, you can define other I/O formats, such as an XML-based
format or a binary format.
@@ -6932,15 +6981,15 @@ and returns it. The functor template is defined in the header file
#include
#include
-typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
-typedef Kernel::FT Number_type;
+using Kernel = CGAL::Exact_predicates_exact_constructions_kernel;
+using Number_type = Kernel::FT;
template struct Edge_length {
// Boost property-type definitions.
- typedef boost::readable_property_map_tag category;
- typedef Number_type value_type;
- typedef value_type reference;
- typedef typename Arrangement::Halfedge_handle key_type;
+ using category = boost::readable_property_map_tag;
+ using value_type = Number_type;
+ using reference = value_type;
+ using key_type = typename Arrangement::Halfedge_handle;
value_type operator()(typename Arrangement::Halfedge_handle e) const {
const auto diff_x = e->target()->point().x() - e->source()->point().x();
@@ -7023,13 +7072,13 @@ header file `Extended_face_property_map.h` listed below.
// A property map that reads/writes the information to/from the extended face.
template class Extended_face_property_map {
public:
- typedef typename Arrangement::Face_handle Face_handle;
+ using Face_handle = typename Arrangement::Face_handle;
// Boost property type definitions.
- typedef boost::read_write_property_map_tag category;
- typedef Type value_type;
- typedef value_type& reference;
- typedef Face_handle key_type;
+ using category = boost::read_write_property_map_tag;
+ using value_type = Type;
+ using reference = value_type&;
+ using key_type = Face_handle;
// The get function is required by the property map concept.
friend reference get(const Extended_face_property_map& map, key_type key)
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Aos_observer.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Aos_observer.h
index 2f21f4a886c..95839a6c344 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Aos_observer.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Aos_observer.h
@@ -23,26 +23,25 @@ namespace CGAL {
template
class Aos_observer {
public:
-
/// \name Types
/// @{
- //! the type of the associated arrangement.
+ /// the type of the associated arrangement.
typedef unspecified_type Arrangement_2;
- //! the point type.
+ /// the point type.
typedef typename Arrangement_2::Point_2 Point_2;
- //! the \f$x\f$-monotone curve type.
+ /// the \f$x\f$-monotone curve type.
typedef typename Arrangement_2::X_monotone_curve_2 X_monotone_curve_2;
- //! the type of a handle to an arrangement vertex.
+ /// the type of a handle to an arrangement vertex.
typedef typename Arrangement_2::Vertex_handle Vertex_handle;
- //! the type of a handle to an arrangement halfedge.
+ /// the type of a handle to an arrangement halfedge.
typedef typename Arrangement_2::Halfedge_handle Halfedge_handle;
- //! the type of a handle to an arrangement face.
+ /// the type of a handle to an arrangement face.
typedef typename Arrangement_2::Face_handle Face_handle;
/*! represents a connected component of the boundary (CCB), either an outer
@@ -77,11 +76,11 @@ public:
/// \name Notifications on Global Arrangement Operations
/// @{
- /*! issued just before the attached arrangement is assigned with the contents of another
- * arrangement.
- * \param arr The other arrangement. Notice that the arrangement type is the type used to
- * instantiate the observer, which is conveniently defined as
- * `Arrangement_2::Base_aos`.
+ /*! issued just before the attached arrangement is assigned with the contents
+ * of another arrangement.
+ * \param arr The other arrangement. Notice that the arrangement type is the
+ * type used to instantiate the observer, which is conveniently
+ * defined as `Arrangement_2::Base_aos`.
*/
virtual void before_assign(const typename Arrangement_2::Base_aos& arr);
@@ -419,6 +418,6 @@ public:
virtual void after_remove_inner_ccb(Face_handle f);
/// @}
-
}; /* end Aos_observer */
+
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h
index 7976f939c74..671cb517e79 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h
@@ -1,303 +1,265 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ *
+ * The traits class `Arr_Bezier_curve_traits_2` is a model of the `AosTraits_2`
+ * concept that handles planar Bézier curves. A planar Bézier
+ * curve \f$B\f$ is a parametric curve defined by a sequence of control
+ * points \f$p_0, \ldots, p_n\f$ as follows:
-The traits class `Arr_Bezier_curve_traits_2` is a model of the `ArrangementTraits_2`
-concept that handles planar Bézier curves. A planar Bézier curve
-\f$ B\f$ is a parametric curve defined by a sequence of control points
-\f$ p_0, \ldots, p_n\f$ as follows:
-
-
-\f{eqnarray*}{
-B(t) = \left(X(t), Y(t)\right)
-= \ccSum{k=0}{n}{p_k \cdot \frac{n!}{k! (n-k)!} \cdot
-t^k (1-t)^{n-k}}\ .
+ * \f{eqnarray*}{
+ * B(t) = \left(X(t), Y(t)\right) = \ccSum{k=0}{n}{p_k \cdot \frac{n!}{k! (n-k)!} \cdot t^k (1-t)^{n-k}}\ ,
\f}
-where \f$ t \in [0, 1]\f$. The degree of the curve is therefore \f$ n\f$ -
-namely, \f$ X(t)\f$ and \f$ Y(t)\f$ are polynomials of degree \f$ n\f$. Bézier curves
-have numerous applications in computer graphics and solid modelling. They
-are used, for example, in free-form sketches and for defining the true-type
-fonts.
+ * where \f$t \in [0, 1]\f$. The degree of the curve is therefore \f$n\f$,
+ * namely, \f$X(t)\f$ and \f$Y(t)\f$ are polynomials of degree \f$n\f$.
+ * Bézier curves have numerous applications in computer graphics and
+ * solid modelling. They are used, for example, in free-form sketches and for
+ * defining the true-type fonts.
-In our representation, we assume that the coordinates of all control
-points are rational numbers (namely they are given as objects of the
-`RatKernel::Point_2` type), so both \f$ X(t)\f$ and \f$ Y(t)\f$ are polynomials
-with rational coefficients. The intersection points between curves are
-however algebraic numbers, and their exact computation is time-consuming.
-The traits class therefore contains a layer of geometric filtering that
-performs all computation in an approximate manner whenever possible, and
-it resorts to exact computations only when the approximate computation
-fails to produce an unambiguous result.
+ * In our representation, we assume that the coordinates of all control points
+ * are rational numbers (namely they are given as objects of the
+ * `RatKernel::Point_2` type), so both \f$X(t)\f$ and \f$Y(t)\f$ are
+ * polynomials with rational coefficients. The intersection points between
+ * curves are however algebraic numbers, and their exact computation is
+ * time-consuming. The traits class therefore contains a layer of geometric
+ * filtering that performs all computation in an approximate manner whenever
+ * possible, and it resorts to exact computations only when the approximate
+ * computation fails to produce an unambiguous result.
-We therefore require separate representations of the control points and
-the intersection points. The `NtTraits` should be instantiated with a class
-that defines nested `Integer`, `Rational` and `Algebraic` number
-types and supports various operations on them, yielding certified computation
-results (for example, in can convert rational numbers to algebraic numbers
-and can compute roots of polynomials with integer coefficients).
-The other template parameters, `RatKernel` and `AlgKernel` should be
-geometric kernels templated with the `NtTraits::Rational` and
-`NtTraits::Algebraic` number types, respectively. It is recommended to
-instantiate the `CORE_algebraic_number_traits` class as the `NtTraits`
-parameter, with `Cartesian` and
-`Cartesian` instantiating the two kernel types,
-respectively. The number types in this case are provided by the \core
-library, with its ability to exactly represent simple algebraic numbers.
+ * We therefore require separate representations of the control points and the
+ * intersection points. The `NtTraits` should be instantiated with a class that
+ * defines nested `Integer`, `Rational` and `Algebraic` number types and
+ * supports various operations on them, yielding certified computation results
+ * (for example, in can convert rational numbers to algebraic numbers and can
+ * compute roots of polynomials with integer coefficients). The other template
+ * parameters, `RatKernel` and `AlgKernel` should be geometric kernels templated
+ * with the `NtTraits::Rational` and `NtTraits::Algebraic` number types,
+ * respectively. It is recommended to instantiate the
+ * `CORE_algebraic_number_traits` class as the `NtTraits` parameter, with
+ * `Cartesian` and `Cartesian`
+ * instantiating the two kernel types, respectively. The number types in this
+ * case are provided by the \core library, with its ability to exactly represent
+ * simple algebraic numbers.
-While `Arr_Bezier_curve_traits_2` models the concept
-`ArrangementDirectionalXMonotoneTraits_2`, the implementation of
-the `Are_mergeable_2` operation does not enforce the input curves
-to have the same direction as a precondition. Moreover, `Arr_Bezier_curve_traits_2`
-supports the merging of curves of opposite directions.
-
-\cgalModels{ArrangementTraits_2,ArrangementDirectionalXMonotoneTraits_2}
-
-
-*/
-template< typename RatKernel, typename AlgKernel, typename NtTraits >
+ * While `Arr_Bezier_curve_traits_2` models the concept
+ * `AosDirectionalXMonotoneTraits_2`, the implementation of the
+ * `Are_mergeable_2` operation does not enforce the input curves to have the
+ * same direction as a precondition. Moreover, `Arr_Bezier_curve_traits_2`
+ * supports the merging of curves of opposite directions.
+ *
+ * \cgalModels{AosTraits_2,AosDirectionalXMonotoneTraits_2}
+ */
+template
class Arr_Bezier_curve_traits_2 {
public:
-/// \name Types
-/// @{
+ /// \name Types
+ /// @{
-/*!
-the `NtTraits::Rational` type
-(and also the `RatKernel::FT` type).
-*/
-typedef unspecified_type Rational;
+ /*! the `NtTraits::Rational` type (and also the `RatKernel::FT` type).
+ */
+ typedef unspecified_type Rational;
-/*!
-the `NtTraits::Algebraic` type
-(and also the `AlgKernel::FT` type).
-*/
-typedef unspecified_type Algebraic;
+ /*! the `NtTraits::Algebraic` type (and also the `AlgKernel::FT` type).
+ */
+ typedef unspecified_type Algebraic;
-/// @}
+ /// @}
+ /*! The `Curve_2` class nested within the Bézier traits class is used
+ * to represent a Bézier curve of arbitrary degree, which is defined by
+ * a sequence of rational control points. In addition to the methods listed
+ * below, the I/O operators \link PkgArrangementOnSurface2op_left_shift
+ * `operator<<` \endlink and \link PkgArrangementOnSurface2op_right_shift
+ * `operator>>` \endlink for standard output-streams are also supported. The
+ * copy constructor and assignment operator are supported as well.
+ */
+ class Curve_2 {
+ public:
-/*!
+ /// \name Creation
+ /// @{
+ /*! default constructor.
+ */
+ Curve_2();
-The `Curve_2` class nested within the Bézier traits class is used
-to represent a Bézier curve of arbitrary degree, which is defined by a
-sequence of rational control points. In addition to the methods listed
-below, the I/O operators \link PkgArrangementOnSurface2op_left_shift `operator<<` \endlink and \link PkgArrangementOnSurface2op_right_shift `operator>>` \endlink for
-standard output-streams are also supported. The copy constructor and
-assignment operator are supported as well.
+ /*! constructs a Bézier curve as defined by the given range of
+ * control points. The value-type of `InputIterator` is
+ * `RatKernel::Point_2`.
+ *
+ * \pre The input range must contain at least two control points.
+ */
+ template
+ Curve_2(InputIterator pts_begin, InputIterator pts_end);
-*/
-class Curve_2 {
-public:
+ /// @}
-/// \name Creation
-/// @{
+ /// \name Access Functions
+ /// @{
-/*!
-default constructor.
-*/
-Curve_2 ();
+ /*! returns the number of control points that define `B`.
+ */
+ std::size_t number_of_control_points() const;
-/*!
-constructs a Bézier curve as defined by the given range of control
-points. The value-type of `InputIterator` is `RatKernel::Point_2`.
-\pre The input range must contain at least two control points.
+ /*! returns the \f$k\f$th control point. Note that the first control point
+ * equals the curve source, while the last control point equals its
+ * target. The rest of the control points do not lie on the curve.
+ *
+ * \pre \f$k\f$ is smaller than the number of control points.
+ */
+ typename RatKernel::Point_2 control_point(std::size_t k) const;
-*/
-template
-Curve_2 (InputIterator pts_begin, InputIterator pts_end);
+ /*! returns the point \f$B(t)\f$ on the curve that corresponds to the given
+ * rational parameter value.
+ */
+ typename RatKernel::Point_2 operator()(const Rational& t) const;
-/// @}
+ /*! returns the point \f$B(t)\f$ on the curve that corresponds to the given
+ * algebraic parameter value.
+ */
+ typename AlgKernel::Point_2 operator()(const Algebraic& t) const;
-/// \name Access Functions
-/// @{
+ /// @}
-/*!
-returns the number of control points that define `B`.
-*/
-size_t number_of_control_points () const;
+ }; /* end Arr_Bezier_curve_traits_2::Curve_2 */
-/*!
-returns the \f$ k\f$th control point. Note that the first control point equals
-the curve source, while the last control point equals its target. The rest
-of the control points do not lie on the curve.
-\pre \f$ k\f$ is smaller than the number of control points.
-*/
-typename RatKernel::Point_2 control_point (size_t k) const;
+ /*! The `Point_2` class nested within the Bézier traits class is used
+ * to represent: (i) an endpoint of a Bézier curve, (ii) a vertical
+ * tangency point of a curve, used to subdivide it into \f$x\f$-monotone
+ * subcurve, and (iii) an intersection point between two curves. While, points
+ * of type (i) have rational coordinates and are given as part of the input,
+ * points of the two latter types have algebraic coordinates. However, to
+ * speed up the arrangement construction, such point are not computed in an
+ * exact manner, and instead are given in an approximate representation. Note
+ * that the exact coordinates of a point may only be accessed if it is exactly
+ * computed.
-/*!
-returns the point \f$ B(t)\f$ on the curve that corresponds to the given
-rational parameter value.
-*/
-typename RatKernel::Point_2 operator() (const Rational& t) const;
+ * In addition to the methods listed below, the copy constructor and assignment
+ * operator for `Point_2` objects are also supported.
+ */
+ class Point_2 {
+ public:
-/*!
-returns the point \f$ B(t)\f$ on the curve that corresponds to the given
-algebraic parameter value.
-*/
-typename AlgKernel::Point_2 operator() (const Algebraic& t) const;
+ /// \name Creation
+ /// @{
-/// @}
+ /*!
+ default constructor.
+ */
+ Point_2();
-}; /* end Arr_Bezier_curve_traits_2::Curve_2 */
+ /*!
+ constructs the point \f$B(t_0)\f$ on the given curve. As \f$t_0\f$ is an
+ algebraic number, the point has algebraic coordinates.
+ */
+ Point_2(const Curve_2& B, const Algebraic& t_0);
+ /*!
+ constructs the point \f$B(t_0)\f$ on the given curve. As \f$t_0\f$ is a
+ rational number, the point has rational coordinates.
+ */
+ Point_2(const Curve_2& B, const Rational& t_0);
-/*!
+ /// @}
-The `Point_2` class nested within the Bézier traits class is used
-to represent: (i) an endpoint of a Bézier curve, (ii) a vertical tangency
-point of a curve, used to subdivide it into \f$ x\f$-monotone subcurve, and
-(iii) an intersection point between two curves. While, points of type (i) have
-rational coordinates and are given as part of the input, points of the two
-latter types have algebraic coordinates. However, to speed up the arrangement
-construction, such point are not computed in an exact manner, and instead
-are given in an approximate representation. Note that the exact coordinates
-of a point may only be accessed if it is exactly computed.
+ /// \name Access Functions
+ /// @{
-In addition to the methods listed below, the copy constructor and assignment
-operator for `Point_2` objects are also supported.
+ /*! returns the approximated coordinates of `p`.
+ */
+ std::pair approximate() const;
-*/
-class Point_2 {
-public:
+ /*! returns whether the coordinates of `p` are computed in an exact manner.
+ */
+ bool is_exact() const;
-/// \name Creation
-/// @{
+ /*! returns the \f$x\f$-coordinate of `p`.
+ *
+ * \pre `p` is exactly computed.
+ */
+ Algebraic x() const;
-/*!
-default constructor.
-*/
-Point_2 ();
+ /*! returns the \f$y\f$-coordinate of `p`.
+ *
+ * \pre `p` is exactly computed.
+ */
+ Algebraic y() const;
-/*!
-constructs the point \f$ B(t_0)\f$ on the given curve. As \f$ t_0\f$ is an
-algebraic number, the point has algebraic coordinates.
-*/
-Point_2 (const Curve_2& B, const Algebraic& t_0);
+ /*! returns whether the coordinates of `p` are rational numbers.
+ */
+ bool is_rational() const;
-/*!
-constructs the point \f$ B(t_0)\f$ on the given curve. As \f$ t_0\f$ is a
-rational number, the point has rational coordinates.
-*/
-Point_2 (const Curve_2& B, const Rational& t_0);
+ /*! casts `p` to a point with rational coordinates.
+ * \pre `p` has rational coordinates.
+ */
+ operator typename RatKernel::Point_2() const;
-/// @}
+ /// @}
-/// \name Access Functions
-/// @{
+ }; /* end Arr_Bezier_curve_traits_2::Point_2 */
-/*!
-returns the approximated coordinates of `p`.
-*/
-std::pair approximate () const;
+ /*! The `X_monotone_curve_2` class nested within the Bézier traits is
+ * used to represent \f$x\f$-monotone subcurves of Bézier curves. The
+ * subcurve is defined by a supporting Bézier curve \f$B(t)\f$ and a
+ * range of definition in the parameter space \f$[t_1, t_2] \subseteq [0,1]\f$,
+ * where \f$B(t_1)\f$ is the subcurve source and \f$B(t_2)\f$ is its target.
+ * Note that as the point endpoints may only be approximated, the parameter
+ * range defining the subcurve may only be approximately known.
+ *
+ * It is not possible to construct \f$x\f$-monotone subcurves directly.
+ * Instead, use the `Make_x_monotone_2` functor supplied by the traits class to
+ * subdivide a `Curve_2` object into \f$x\f$-monotone subcurves.
+ */
+ class X_monotone_curve_2 {
+ public:
-/*!
-returns whether the coordinates of `p` are computed in an exact manner.
-*/
-bool is_exact () const;
+ /// \name Access Functions
+ /// @{
-/*!
-returns the \f$ x\f$-coordinate of `p`.
-\pre `p` is exactly computed.
-*/
-Algebraic x () const;
+ /*! returns the supporting Bézier curve of `b`.
+ */
+ Curve_2 supporting_curve() const;
-/*!
-returns the \f$ y\f$-coordinate of `p`.
-\pre `p` is exactly computed.
-*/
-Algebraic y () const;
+ /*! returns the source point of `b`.
+ */
+ Point_2 source() const;
-/*!
-returns whether the coordinates of `p` are rational numbers.
-*/
-bool is_rational () const;
+ /*! returns the target point of `b`.
+ */
+ Point_2 target() const;
-/*!
-casts `p` to a point with rational coordinates.
-\pre `p` has rational coordinates.
-*/
-operator typename RatKernel::Point_2 () const;
+ /*! returns the left (\f$xy\f$-lexicographically smaller) endpoint of `b`.
+ */
+ Point_2 left() const;
-/// @}
+ /*! returns the right (\f$xy\f$-lexicographically smaller) endpoint of `b`.
+ */
+ Point_2 right() const;
-}; /* end Arr_Bezier_curve_traits_2::Point_2 */
+ /*! return the approximate parameter range defining the subcurve `b`.
+ */
+ std::pair parameter_range() const;
-/*!
+ /// @}
+ }; /* end Arr_Bezier_curve_traits_2::X_monotone_curve_2 */
-The `X_monotone_curve_2` class nested within the Bézier traits is
-used to represent \f$ x\f$-monotone subcurves of Bézier curves. The subcurve is
-defined by a supporting Bézier curve \f$ B(t)\f$ and a range of definition in
-the parameter space \f$ [t_1, t_2] \subseteq [0, 1]\f$, where \f$ B(t_1)\f$ is the
-subcurve source and \f$ B(t_2)\f$ is its target. Note that as the point endpoints
-may only be approximated, the parameter range defining the subcurve may
-only be approximately known.
+ class Trim_2 {
+ public:
+ /// \name Creation
+ /// @{
-It is not possible to construct \f$ x\f$-monotone subcurves directly. Instead,
-use the `Make_x_monotone_2` functor supplied by the traits class to
-subdivide a `Curve_2` object into \f$ x\f$-monotone subcurves.
+ /*! Trims the given \f$x\f$-monotone curve to an from `src` to `tgt`.
+ *
+ * \ pre `src` and `tgt` lies on the curve
+ */
+ X_monotone_curve_2(const X_monotone_curve_2& xcv,
+ const Point_2& src, const Point_2& tgt) const
-*/
-class X_monotone_curve_2 {
-public:
+ /// @}
-/// \name Access Functions
-/// @{
-
-/*!
-returns the supporting Bézier curve of `b`.
-*/
-Curve_2 supporting_curve () const;
-
-/*!
-returns the source point of `b`.
-*/
-Point_2 source () const;
-
-/*!
-returns the target point of `b`.
-*/
-Point_2 target () const;
-
-/*!
-returns the left (\f$ xy\f$-lexicographically smaller) endpoint of `b`.
-*/
-Point_2 left () const;
-
-/*!
-returns the right (\f$ xy\f$-lexicographically smaller) endpoint of `b`.
-*/
-Point_2 right () const;
-
-/*!
-return the approximate parameter range defining the subcurve `b`.
-*/
-std::pair parameter_range () const;
-
-/// @}
-
-}; /* end Arr_Bezier_curve_traits_2::X_monotone_curve_2 */
-
-class Trim_2{
-public:
-/// \name Creation
-/// @{
-
-/*!
-Trims the given x-monotone curve to an from src to tgt.
-\ pre `src` and `tgt` lies on the curve
-*/
-
-X_monotone_curve_2(const X_monotone_curve_2& xcv,
- const Point_2& src,
- const Point_2& tgt)const
-
-/// @}
-
-}/* end Arr_Bezier_curve_traits_2::Trim_2 */
+ } /* end Arr_Bezier_curve_traits_2::Trim_2 */
}; /* end Arr_Bezier_curve_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_accessor.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_accessor.h
index 786eacc5092..922ebd42db8 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_accessor.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_accessor.h
@@ -18,122 +18,123 @@ namespace CGAL {
template
class Arr_accessor {
public:
+ /// \name Types
+ /// @{
-/// \name Types
-/// @{
+ /*! the type of the associated arrangement. */
+ typedef unspecified_type Arrangement_2;
-/*! the type of the associated arrangement. */
-typedef unspecified_type Arrangement_2;
+ /*! the point type. */
+ typedef typename Arrangement_2::Point_2 Point_2;
-/*! the point type. */
-typedef typename Arrangement_2::Point_2 Point_2;
+ /*! the \f$x\f$-monotone curve type. */
+ typedef typename Arrangement_2::X_monotone_curve_2 X_monotone_curve_2;
-/*! the \f$ x\f$-monotone curve type. */
+ /*! */
+ typedef typename Arrangement_2::Vertex_handle Vertex_handle;
-typedef typename Arrangement_2::X_monotone_curve_2 X_monotone_curve_2;
+ /*! */
+ typedef typename Arrangement_2::Halfedge_handle Halfedge_handle;
-/*! */
-typedef typename Arrangement_2::Vertex_handle Vertex_handle;
+ /*! */
+ typedef typename Arrangement_2::Face_handle Face_handle;
-/*! */
-typedef typename Arrangement_2::Halfedge_handle Halfedge_handle;
+ /*! represents the boundary of a connected component (CCB). */
+ typedef typename Arrangement_2::Ccb_halfedge_circulator Ccb_halfedge_circulator;
-/*! */
-typedef typename Arrangement_2::Face_handle Face_handle;
+ /// @}
-/*! represents the boundary of a connected component (CCB). */
-typedef typename Arrangement_2::Ccb_halfedge_circulator Ccb_halfedge_circulator;
+ /// \name Creation
+ /// @{
-/// @}
+ /*! constructs an accessor attached to the given arrangement `arr`. */
+ Arr_accessor(Arrangement_2& arr);
-/// \name Creation
-/// @{
+ /// @}
-/*! constructs an accessor attached to the given arrangement `arr`. */
-Arr_accessor(Arrangement_2& arr);
+ /// \name Accessing the Notification Functions
-/// @}
+ /// @{
-/// \name Accessing the Notification Functions
+ /*! notifies the arrangement observer that a global change is going to take
+ * place (for the usage of the global functions that operate on arrangements).
+ */
+ void notify_before_global_change();
-/// @{
+ /*! notifies the arrangement observer that a global change has taken place
+ * (for the usage of the global functions that operate on arrangements).
+ */
+ void notify_after_global_change();
-/*! notifies the arrangement observer that a global change is going to take
- * place (for the usage of the global functions that operate on arrangements).
- */
-void notify_before_global_change();
+ /// @}
-/*! notifies the arrangement observer that a global change has taken place (for
- * the usage of the global functions that operate on arrangements).
- */
-void notify_after_global_change();
+ /// \name Arrangement Predicates
+ /// @{
-/// @}
+ /*! locates a place for the curve `c` around the vertex `v` and returns a
+ * halfedge whose target is `v`, where c should be inserted between this
+ * halfedge and the next halfedge around `v` in a clockwise order.
+ */
+ Halfedge_handle
+ locate_around_vertex(Vertex_handle v, const X_monotone_curve_2& c) const;
-/// \name Arrangement Predicates
-/// @{
+ /*! counts the number of edges along the path from `e1` to `e2`. In case the
+ * two halfedges do not belong to the same connected component, the function
+ * returns (-1).
+ */
+ int halfedge_distance(Halfedge_const_handle e1,
+ Halfedge_const_handle e2) const;
-/*! locates a place for the curve `c` around the vertex `v` and returns a
- * halfedge whose target is `v`, where c should be inserted between this
- * halfedge and the next halfedge around `v` in a clockwise order.
- */
-Halfedge_handle
-locate_around_vertex(Vertex_handle v, const X_monotone_curve_2& c) const;
+ /*! determines whether a new halfedge we are about to create, which is to be
+ * associated with the curve `c` and directed from `pred1->target()` to
+ * `pred2->target()`, lies on the inner CCB of the new face that will be
+ * created, introducing this new edge.
+ *
+ * \pre `pred1->target()` and `pred2->target()` are associated with `c`'s
+ * endpoints.
+ *
+ * \pre `pred1` and `pred2` belong to the same connected component, such that
+ * a new face is created by connecting `pred1->target()` and
+ * `pred2->target()`.
+ */
+ bool is_inside_new_face(Halfedge_handle pred1,
+ Halfedge_handle pred2,
+ const X_monotone_curve_2& c) const;
-/*! counts the number of edges along the path from `e1` to `e2`. In case the
- * two halfedges do not belong to the same connected component, the function
- * returns (-1).
-*/
-int halfedge_distance(Halfedge_const_handle e1, Halfedge_const_handle e2) const;
+ /*! determines whether a given point lies within the region bounded by a
+ * boundary of the connected component that `he` belongs to. Note that if the
+ * function returns `true`, then `p` is contained within `he->face()` (but not
+ * on its boundary), or inside one of the inner CCBs of this face, or it may
+ * coincide with an isolated vertex in this face.
+ */
+ bool point_is_in(const Point_2& p, Halfedge_const_handle he) const;
-/*! determines whether a new halfedge we are about to create, which is to be
- * associated with the curve `c` and directed from `pred1->target()` to
- * `pred2->target()`, lies on the inner CCB of the new face that will be
- * created, introducing this new edge.
- *
- * \pre `pred1->target()` and `pred2->target()` are associated with `c`'s
- * endpoints.
- *
- * \pre `pred1` and `pred2` belong to the same connected component, such that a
- * new face is created by connecting `pred1->target()` and `pred2->target()`.
-*/
-bool is_inside_new_face(Halfedge_handle pred1,
-Halfedge_handle pred2,
-const X_monotone_curve_2& c) const;
+ /*! determines whether `he` lies on the outer boundary of its incident face.
+ */
+ bool is_on_outer_boundary(Halfedge_const_handle he) const;
-/*! determines whether a given point lies within the region bounded by a
- * boundary of the connected component that `he` belongs to. Note that if the
- * function returns `true`, then `p` is contained within `he->face()` (but not
- * on its boundary), or inside one of the inner CCBs of this face, or it may
- * coincide with an isolated vertex in this face.
- */
-bool point_is_in(const Point_2& p, Halfedge_const_handle he) const;
+ /*! determines whether `he` lies on the inner boundary of its incident face
+ * (that is, whether it lies on the boundary of one of the inner CCBs of this
+ * face).
+ */
+ bool is_on_inner_boundary(Halfedge_const_handle he) const;
-/*! determines whether `he` lies on the outer boundary of its incident face. */
-bool is_on_outer_boundary(Halfedge_const_handle he) const;
+ /// @}
-/*! determines whether `he` lies on the inner boundary of its incident face
- * (that is, whether it lies on the boundary of one of the inner CCBs of this
- * face).
- */
-bool is_on_inner_boundary(Halfedge_const_handle he) const;
+ /// \name Arrangement Modifiers
+ /// @{
-/// @}
-
-/// \name Arrangement Modifiers
-/// @{
-
-/*! creates a new vertex an associates it with the point `p`.
- *
- * \pre There is no existing vertex already associated with `p`.
- */
-Vertex_handle create_vertex(const Point_2& p);
+ /*! creates a new vertex an associates it with the point `p`.
+ *
+ * \pre There is no existing vertex already associated with `p`.
+ */
+ Vertex_handle create_vertex(const Point_2& p);
/*! inserts the curve `c` as a new inner CCBs (hole) of the face `f`,
* connecting the two isolated vertices `v1` and `v2`. `res` is the comparison
* result between these two end-vertices. The function returns a handle for one
- * of the new halfedges corresponding to the inserted curve, directed from `v1`
- * to `v2`.
+ * one of the new halfedges corresponding to the inserted curve, directed from
+ * `v1` to `v2`.
*
* \pre `v1` and `v2` are associated with `c`'s endpoints, that they lie of
* `f`'s interior and that and that they have no incident edges.
@@ -160,121 +161,122 @@ Halfedge_handle insert_from_vertex_ex(const X_monotone_curve_2& c,
Vertex_handle v,
Comparison_result res);
-/*! inserts the curve `c` into the arrangement, such that both `c`'s endpoints
- * correspond to existing arrangement vertices, given by `pred1->target()` and
- * `pred2->target()`. `res` is the comparison result between these two
- * end-vertices. The function creates a new halfedge pair that connects the two
- * vertices (with `pred1` and `pred2` indicate the exact place for these
- * halfedges around the two target vertices) and returns a handle for the
- * halfedge directed from `pred1->target()` to `pred2->target()`. The output
- * flag `new_face` indicates whether a new face has been created following the
- * insertion of the new curve.
- *
- * \pre `pred1->target()` and `pred2->target()` are associated with `c`'s
- * endpoints and that if a new face is created, then `is_inside_new_face (pred1,
- * pred2, c)` is `true`.
- */
-Halfedge_handle insert_at_vertices_ex(const X_monotone_curve_2& c,
- Halfedge_handle pred1,
- Halfedge_handle pred2,
- Comparison_result res, bool& new_face);
+ /*! inserts the curve `c` into the arrangement, such that both `c`'s endpoints
+ * correspond to existing arrangement vertices, given by `pred1->target()` and
+ * `pred2->target()`. `res` is the comparison result between these two
+ * end-vertices. The function creates a new halfedge pair that connects the
+ * two vertices (with `pred1` and `pred2` indicate the exact place for these
+ * halfedges around the two target vertices) and returns a handle for the
+ * halfedge directed from `pred1->target()` to `pred2->target()`. The output
+ * flag `new_face` indicates whether a new face has been created following the
+ * insertion of the new curve.
+ *
+ * \pre `pred1->target()` and `pred2->target()` are associated with `c`'s
+ * endpoints and that if a new face is created, then
+ * `is_inside_new_face(pred1, pred2, c)` is `true`.
+ */
+ Halfedge_handle insert_at_vertices_ex(const X_monotone_curve_2& c,
+ Halfedge_handle pred1,
+ Halfedge_handle pred2,
+ Comparison_result res, bool& new_face);
-/*! inserts `v` as an isolated vertex inside `f`.
- *
- * \pre `v->point()` is contained in the interior of the given face.
- */
-void insert_isolated_vertex(Face_handle f, Vertex_handle v);
+ /*! inserts `v` as an isolated vertex inside `f`.
+ *
+ * \pre `v->point()` is contained in the interior of the given face.
+ */
+ void insert_isolated_vertex(Face_handle f, Vertex_handle v);
-/*! moves the given hole (inner CCB) from the interior of the face `f1` to the
- * face `f2`.
- *
- * \pre `hole` is currently contained in `f1` and should be moved to `f2`.
- */
-void move_hole(Face_handle f1, Face_handle f2, Ccb_halfedge_circulator hole);
+ /*! moves the given hole (inner CCB) from the interior of the face `f1` to the
+ * face `f2`.
+ *
+ * \pre `hole` is currently contained in `f1` and should be moved to `f2`.
+ */
+ void move_hole(Face_handle f1, Face_handle f2, Ccb_halfedge_circulator hole);
-/*! moves the given isolated vertex from the interior of the face `f1`
- * inside the face `f2`.
- *
- * \pre `v` is indeed an isolated vertex currently contained in `f1` and should
- * be moved to `f2`.
- */
-bool move_isolated_vertex(Face_handle f1, Face_handle f2, Vertex_handle v);
+ /*! moves the given isolated vertex from the interior of the face `f1`
+ * inside the face `f2`.
+ *
+ * \pre `v` is indeed an isolated vertex currently contained in `f1` and
+ * should be moved to `f2`.
+ */
+ bool move_isolated_vertex(Face_handle f1, Face_handle f2, Vertex_handle v);
-/*! relocates all inner ccbs and isolated vertices to their proper position
- * immediately after a face has split due to the insertion of a new halfedge,
- * namely after `insert_at_vertices_ex()` was invoked and indicated that a new
- * face has been created. `he` is the halfedge returned by
- * `insert_at_vertices_ex()`, such that `he->twin()->face` is the face that has
- * just been split and `he->face()` is the newly created face.
- */
-void relocate_in_new_face(Halfedge_handle he);
+ /*! relocates all inner ccbs and isolated vertices to their proper position
+ * immediately after a face has split due to the insertion of a new halfedge,
+ * namely after `insert_at_vertices_ex()` was invoked and indicated that a new
+ * face has been created. `he` is the halfedge returned by
+ * `insert_at_vertices_ex()`, such that `he->twin()->face` is the face that
+ * has just been split and `he->face()` is the newly created face.
+ */
+ void relocate_in_new_face(Halfedge_handle he);
-/*! relocates all inner ccbs in a new face, as detailed above. */
-void relocate_holes_in_new_face(Halfedge_handle he);
+ /*! relocates all inner ccbs in a new face, as detailed above. */
+ void relocate_holes_in_new_face(Halfedge_handle he);
-/*! relocates all isolated vertices in a new face, as detailed above. */
-void relocate_isolated_vertices_in_new_face(Halfedge_handle he);
+ /*! relocates all isolated vertices in a new face, as detailed above. */
+ void relocate_isolated_vertices_in_new_face(Halfedge_handle he);
-/*! modifies the point associated with the vertex `v` (the point may be
- * geometrically different than the one currently associated with `v`). The
- * function returns a handle to the modified vertex (same as `v`).
- *
- * \pre No other arrangement vertex is already associated with `p`.
- *
- * \pre The topology of the arrangement does not change after the vertex point
- * is modified.
- */
-Vertex_handle modify_vertex_ex(Vertex_handle v, const Point_2& p);
+ /*! modifies the point associated with the vertex `v` (the point may be
+ * geometrically different than the one currently associated with `v`). The
+ * function returns a handle to the modified vertex (same as `v`).
+ *
+ * \pre No other arrangement vertex is already associated with `p`.
+ *
+ * \pre The topology of the arrangement does not change after the vertex point
+ * is modified.
+ */
+ Vertex_handle modify_vertex_ex(Vertex_handle v, const Point_2& p);
-/*! modifies the \f$ x\f$-monotone curve associated with the edge `e` (the curve
- * `c` may be geometrically different than the one currently associated with
- * `e`). The function returns a handle to the modified edge (same as `e`).
- *
- * \pre The interior of `c` is disjoint from all existing arrangement vertices
- * and edges.
- */
-Halfedge_handle modify_edge_ex(Halfedge_handle e, const X_monotone_curve_2& c);
+ /*! modifies the \f$x\f$-monotone curve associated with the edge `e` (the
+ * curve `c` may be geometrically different than the one currently associated
+ * with `e`). The function returns a handle to the modified edge (same as
+ * `e`).
+ *
+ * \pre The interior of `c` is disjoint from all existing arrangement vertices
+ * and edges.
+ */
+ Halfedge_handle modify_edge_ex(Halfedge_handle e, const X_monotone_curve_2& c);
-/*! splits a given edge into two at the split point `p`, and associate the
- * x-monotone curves `c1` and `c2` with the resulting edges, such that `c1`
- * connects `he->source()` with `p` and `c2` connects `p` with
- * `he->target()`. The function return a handle to the split halfedge directed
- * from `he->source()` to the split point `p`.
- *
- * \pre The endpoints of `c1` and `c2` correspond to `p` and to `he`'s
- * end-vertices, as indicated above.
- */
-Halfedge_handle split_edge_ex(Halfedge_handle he, const Point_2& p,
- const X_monotone_curve_2& c1,
- const X_monotone_curve_2& c2);
+ /*! splits a given edge into two at the split point `p`, and associate the
+ * \f$x\f$-monotone curves `c1` and `c2` with the resulting edges, such that
+ * `c1` connects `he->source()` with `p` and `c2` connects `p` with
+ * `he->target()`. The function return a handle to the split halfedge directed
+ * from `he->source()` to the split point `p`.
+ *
+ * \pre The endpoints of `c1` and `c2` correspond to `p` and to `he`'s
+ * end-vertices, as indicated above.
+ */
+ Halfedge_handle split_edge_ex(Halfedge_handle he, const Point_2& p,
+ const X_monotone_curve_2& c1,
+ const X_monotone_curve_2& c2);
-/*! splits a given edge into two at by the vertex `v`, and associate the
- * x-monotone curves `c1` and `c2` with the resulting edges, such that `c1`
- * connects `he->source()` with `v` and `c2` connects `v` with
- * `he->target()`. The function return a handle to the split halfedge directed
- * from `he->source()` to `v`.
- *
- * \pre The endpoints of `c1` and `c2` correspond to `v` and to `he`'s
- * end-vertices, as indicated above. It is also assumed that `v` has no incident
- * edges.
- */
-Halfedge_handle split_edge_ex(Halfedge_handle he, Vertex_handle v,
- const X_monotone_curve_2& c1,
- const X_monotone_curve_2& c2);
+ /*! splits a given edge into two at by the vertex `v`, and associate the
+ * \f$x\f$-monotone curves `c1` and `c2` with the resulting edges, such that
+ * `c1` connects `he->source()` with `v` and `c2` connects `v` with
+ * `he->target()`. The function return a handle to the split halfedge directed
+ * from `he->source()` to `v`.
+ *
+ * \pre The endpoints of `c1` and `c2` correspond to `v` and to `he`'s
+ * end-vertices, as indicated above. It is also assumed that `v` has no
+ * incident edges.
+ */
+ Halfedge_handle split_edge_ex(Halfedge_handle he, Vertex_handle v,
+ const X_monotone_curve_2& c1,
+ const X_monotone_curve_2& c2);
-/*! removes the edge `he` from the arrangement, such that if the edge removal
- * causes the creation of a new hole (inner CCB), `he->target()` lies on the
- * boundary of this hole. The flags `remove_source` and `remove_target`
- * indicate whether the end-vertices of `he` should be removed as well, in case
- * they have no other incident edges. If the operation causes two faces to
- * merge, the merged face is returned. Otherwise, the face to which the edge
- * was incident is returned.
- */
-Face_handle remove_edge_ex(Halfedge_handle he,
- bool remove_source = true,
- bool remove_target = true);
-
-/// @}
+ /*! removes the edge `he` from the arrangement, such that if the edge removal
+ * causes the creation of a new hole (inner CCB), `he->target()` lies on the
+ * boundary of this hole. The flags `remove_source` and `remove_target`
+ * indicate whether the end-vertices of `he` should be removed as well, in
+ * case they have no other incident edges. If the operation causes two faces
+ * to merge, the merged face is returned. Otherwise, the face to which the
+ * edge was incident is returned.
+ */
+ Face_handle remove_edge_ex(Halfedge_handle he,
+ bool remove_source = true,
+ bool remove_target = true);
+ /// @}
}; /* end Arr_accessor */
+
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_algebraic_segment_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_algebraic_segment_traits_2.h
index 27fcce4bb1e..c57c2661e1e 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_algebraic_segment_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_algebraic_segment_traits_2.h
@@ -3,22 +3,22 @@ namespace CGAL {
/*! \ingroup PkgArrangementOnSurface2TraitsClasses
*
* The traits class `Arr_algebraic_segment_traits_2` is a model of the
- * `ArrangementTraits_2` concept that handles planar algebraic curves of
- * arbitrary degree, and \f$ x\f$-monotone of such curves. A planar (real)
- * algebraic curve is the vanishing set of a polynomial in two variables,
- * that is, the curve is defined by the defining equation \f[
- * f(x):=\sum_{i+j\leq n} a_{ij} x^i y^j =0, \f] where \f$ n\f$ is the degree of
- * the curve.
+ * `AosTraits_2` concept that handles planar algebraic curves of arbitrary
+ * degree, and \f$x\f$-monotone of such curves. A planar (real) algebraic
+ * curve is the vanishing set of a polynomial in two variables, that is,
+ * the curve is defined by the defining equation
+ * \f[f(x):=\sum_{i+j\leq n} a_{ij} x^i y^j =0, \f] where \f$n\f$ is the
+ * degree of the curve.
*
* The traits class allows the construction of algebraic curves, by specifying
- * their implicit equation. \f$ x\f$-monotone and vertical segments of a curve
+ * their implicit equation. \f$x\f$-monotone and vertical segments of a curve
* can also be defined; unbounded curves and segments are supported. The
* template parameter `Coefficient` defines the innermost coefficient type of
* the polynomials. Currently, the types `leda::integer` and `CORE::BigInt` are
* supported as well as any instance of `CGAL::Sqrt_extension` that is
* instantiated with one of the integral types above.
*
- * \cgalModels{ArrangementTraits_2}
+ * \cgalModels{AosTraits_2}
*/
template
@@ -50,8 +50,7 @@ public:
*/
typedef unspecified_type Algebraic_real_1;
- /*! Typedef from `Algebraic_kernel_1::Bound`
- */
+ /// Typedef from `Algebraic_kernel_1::Bound`
typedef unspecified_type Bound;
/// @}
@@ -77,7 +76,6 @@ public:
*/
class Construct_curve_2 {
public:
-
/// \name Object Creation Functors
/// @{
@@ -102,40 +100,41 @@ public:
*/
class Construct_point_2 {
public:
-
/// \name Object Creation Functors
/// @{
/*! returns a `Point_2` object that represents the `arcno`-th
- * point in the fiber of `cv` at \f$ x\f$-coordinate `x`,
+ * point in the fiber of `cv` at \f$x\f$-coordinate `x`,
* counted from the bottom, starting with zero.
+ *
* \pre (`cv` must not have a vertical line at `x`,
- * and \f$ 0\leq arcno < c\f$, where \f$ c\f$ is the number of points
+ * and \f$0\leq arcno < c\f$, where \f$c\f$ is the number of points
* in the fiber of `cv` at `x`.)
*/
- Point_2 operator() (Algebraic_real_1 x, Curve_2 cv, int arcno);
+ Point_2 operator()(Algebraic_real_1 x, Curve_2 cv, int arcno);
/*! returns a `Point_2` object that represents the
- * point on `xcv` at \f$ x\f$-coordinate `x`
- * \pre (`x` is in the \f$ x\f$-range of `xcv`.)
+ * point on `xcv` at \f$x\f$-coordinate `x`
+ *
+ * \pre (`x` is in the \f$x\f$-range of `xcv`.)
*/
- Point_2 operator() (Algebraic_real_1 x, X_monotone_curve_2 xcv);
+ Point_2 operator()(Algebraic_real_1 x, X_monotone_curve_2 xcv);
/*! returns a `Point_2` object that represents (x,y)
*/
- Point_2 operator() (Algebraic_real_1 x, Algebraic_real_1 y);
+ Point_2 operator()(Algebraic_real_1 x, Algebraic_real_1 y);
/*! returns a `Point_2` object that represents (x,y)
*/
- Point_2 operator() (Coefficient x, Coefficient y);
+ Point_2 operator()(Coefficient x, Coefficient y);
/*! returns a `Point_2` object that represents (x,y)
*/
- Point_2 operator() (Bound x, Bound y);
+ Point_2 operator()(Bound x, Bound y);
/*! returns a `Point_2` object that represents (x,y)
*/
- Point_2 operator() (int x, int y);
+ Point_2 operator()(int x, int y);
/// @}
@@ -145,7 +144,6 @@ public:
*/
class Construct_x_monotone_segment_2 {
public:
-
/// \name Object Creation Functors
/// @{
@@ -162,54 +160,56 @@ public:
*
* \pre `end_min` must have a unique \f$x\f$-monotone segment to its right, or
* `end_max` must have a unique \f$x\f$-monotone segment to its left.
- * Furthermore, `end_min` and `end_max` must be connected by an
- * \f$x\f$-monotone segment of `cv`)
+ * Furthermore, `end_min` and `end_max` must be connected by an
+ * \f$x\f$-monotone segment of `cv`)
*/
template
- OutputIterator operator() (Curve_2 cv, Point_2 end_min, Point_2 end_max,
- OutputIterator oi);
+ OutputIterator operator()(Curve_2 cv, Point_2 end_min, Point_2 end_max,
+ OutputIterator oi);
/*! inserts a sequence of `X_monotone_curve_2` objects into an output container
* given through an output iterator. These segments form an \f$x\f$-monotone
* (or vertical) segment of the curve `cv`.
*
- * If `site_of_p==POINT_IN_INTERIOR`, the maximal segment is
- * returned that contains `p` in its interior.
+ * If `site_of_p` == `POINT_IN_INTERIOR`, the maximal segment that contains
+ * `p` in its interior is returned .
*
- * returned that contains `p` as its left endpoint.
+ * If `site_of_p` == `MIN_ENDPOINT`, the segment that contains
+ * `p` as its left endpoint returned .
*
- * returned that contains `p` as its left endpoint.
+ * If `site_of_p` == `MAX_ENDPOINT`, the segment that contains
+ * `p` as its right endpoint returned .
*
- * \pre (If `site_of_p==POINT_IN_INTERIOR`, `p`
- * must be an interior point of an \f$x\f$-monotone or a vertical
- * segment.
- * must either have a unique \f$x\f$-monotone segment to the right,
- * or a vertical segment from `p` upwards.
- * must either have a unique \f$x\f$-monotone segment to the left,
- * or a vertical segment from `p` downwards.)
+ * \pre If `site_of_p` == `POINT_IN_INTERIOR`, `p` must be an interior point
+ * of an \f$x\f$-monotone or a vertical segment.
+ *
+ * \pre If `site_of_p` == `MIN_ENDPOINT`, `p` must either have a unique
+ * \f$x\f$-monotone segment to the right, or a vertical segment from `p` upwards.
+ *
+ * \pre If `site_of_p` == `MAX_ENDPOINT`, `p` must either have a unique
+ * \f$x\f$-monotone segment to the left, or a vertical segment from `p` downwards.
*/
template
- OutputIterator operator() (Curve_2 cv, Point_2 p, Site_of_point site_of_p,
- OutputIterator out);
+ OutputIterator operator()(Curve_2 cv, Point_2 p, Site_of_point site_of_p,
+ OutputIterator out);
- /*! inserts a sequence of `X_monotone_curve_2` objects into an output container
- * given through an output iterator. These segments form a straight-line
- * segment connecting the points `p` and `q`. If `p` and `q` share the same
- * \f$x\f$-coordinate, the constructed vertical segment consists of only one
- * `X_monotone_curve_2` object and can be computed efficiently. In the
- * non-vertical case, the construction is only possible if `p` and `q` have both
- * rational x- and y-coordinates.
+ /*! inserts a sequence of `X_monotone_curve_2` objects into an output
+ * container given through an output iterator. These segments form a
+ * straight-line segment connecting the points `p` and `q`. If `p` and `q`
+ * share the same \f$x\f$-coordinate, the constructed vertical segment
+ * consists of only one `X_monotone_curve_2` object and can be computed
+ * efficiently. In the non-vertical case, the construction is only possible
+ * if `p` and `q` have both rational \f$x\f$- and \f$y\f$-coordinates.
*
- * \pre (`p` must not be equal to `q`.)
+ * \pre `p` must not be equal to `q`.
*/
template
- OutputIterator operator() (Point_2 p, Point_2 q, OutputIterator out);
+ OutputIterator operator()(Point_2 p, Point_2 q, OutputIterator out);
/// @}
-
}; /* end Arr_algebraic_segment_traits_2::Construct_x_monotone_segment_2 */
- /*! A model of the the `ArrangementTraits_2::Curve_2` concept.
+ /*! A model of the the `AosTraits_2::Curve_2` concept.
* Represents algebraic curves. Internally, the type stores
* topological-geometric information about the particular curve.
* In order to use internal caching, instances should only be created
@@ -223,25 +223,25 @@ public:
/*! returns the defining polynomial of the curve.
*/
- Polynomial_2 polynomial () const;
+ Polynomial_2 polynomial() const;
/// @}
}; /* end Arr_algebraic_segment_traits_2::Curve_2 */
- /*! A model of the `ArrangementBasicTraits_2::Point_2` concept.
- * Represents points in \f$ \mathbb{R}^2\f$. Intersection points of algebraic
+ /*! A model of the `AosBasicTraits_2::Point_2` concept.
+ * Represents points in \f$\mathbb{R}^2\f$. Intersection points of algebraic
* curves are in general non-rational, so we need a data structure that is
* capable of representing arbitrary points with algebraic coordinates.
*
* The traits class represents algebraic coordinates by the type
- * `Algebraic_real_1`, which is a model of the `AlgebraicReal_1` concept.
- * A point \f$ p\f$ is stored by a triple \f$ (x,cv,arcno)\f$,
- * where \f$ x\f$ is the \f$ x\f$-coordinate of a point, \f$ cv\f$ is an instance
- * of `Curve_2` that contains the point, (and has no vertical line at \f$ x\f$),
- * and \f$ arcno\f$ is an `int`, denoting that \f$ p\f$ is met as the
- * \f$arcno\f$-th point when shooting a vertical ray at \f$ x\f$, starting from
- * \f$-\infty\f$ (where counting starts with \f$ 0\f$).
+ * `Algebraic_real_1`, which is a model of the `AlgebraicReal_1` concept. A
+ * point \f$p\f$ is stored by a triple \f$(x,cv,arcno)\f$, where \f$x\f$ is
+ * the \f$x\f$-coordinate of a point, \f$cv\f$ is an instance of `Curve_2`
+ * that contains the point, (and has no vertical line at \f$x\f$), and
+ * \f$arcno\f$ is an `int`, denoting that \f$p\f$ is met as the \f$arcno\f$-th
+ * point when shooting a vertical ray at \f$x\f$, starting from \f$-\infty\f$
+ * (where counting starts with \f$0\f$).
*
* In addition to the methods listed below, the copy constructor and assignment
* operator for `Point_2` objects are also supported.
@@ -251,53 +251,52 @@ public:
class Point_2 {
public:
-
/// \name Modifiers
/// @{
- /*! returns the \f$ x\f$-coordinate of `p`.
+ /*! returns the \f$x\f$-coordinate of `p`.
*/
- Algebraic_real_1 x () const;
+ Algebraic_real_1 x() const;
- /*! returns the \f$ y\f$-coordinates of `p`.
+ /*! returns the \f$y\f$-coordinates of `p`.
*
- * Attention: As described above, points are not stored
- * by their \f$ y\f$-coordinate in `Algebraic_real_1` representation. In fact,
+ * Attention: As described above, points are not stored by their
+ * \f$y\f$-coordinate in `Algebraic_real_1` representation. In fact,
* this representation must be computed on demand, and might become quite
* costly for points defined by high-degree polynomials. Therefore, it is
* recommended to avoid to call this function as much as possible.
*/
- Algebraic_real_1 y () const;
+ Algebraic_real_1 y() const;
/*! returns a `Curve_2` instance that `p`is part of.
*/
- Curve_2 curve () const;
+ Curve_2 curve() const;
/*! returns the arc number of `p`.
*/
- int arcno () const;
+ int arcno() const;
- /*! returns double-approximations of the \f$ x\f$- and \f$ y\f$-coordinates.
+ /*! returns double-approximations of the \f$x\f$- and \f$y\f$-coordinates.
*/
- std::pair to_double () const;
+ std::pair to_double() const;
/// @}
}; /* end Arr_algebraic_segment_traits_2::Point_2 */
- /*! A model of the `ArrangementBasicTraits_2::X_monotone_curve_2` concept.
+ /*! A model of the `AosBasicTraits_2::X_monotone_curve_2` concept.
* Represents terminal segments of an algebraic curves, that means vertical
- * segments or \f$ x\f$-monotone segments with no critical \f$ x\f$-coordinate
- * in the interior of their \f$ x\f$-range. Terminal segments might either be
+ * segments or \f$x\f$-monotone segments with no critical \f$x\f$-coordinate
+ * in the interior of their \f$x\f$-range. Terminal segments might either be
* bounded or unbounded. By definition, each interior point of a non-vertical
* segment has the same arc number (see the documentation of type `Point_2`
* above, which is called the arc number of the segment (note the arc
* number at the endpoints might differ). Such segments are represented
- * internally by a 4-tuple \f$ (p,q,cv,arcno)\f$, where \f$ p\f$ and \f$ q\f$
- * are the endpoints, \f$ cv\f$ is the supporting curve that the segment
- * belongs to, and arcno is the arc number of the segment.
+ * internally by a 4-tuple \f$(p,q,cv,arcno)\f$, where \f$p\f$ and \f$q\f$
+ * are the endpoints, \f$cv\f$ is the supporting curve that the
+ * segment belongs to, and arcno is the arc number of the segment.
*
- * Arbitrary (weakly) \f$ x\f$-monotone segments are presented by a range
+ * Arbitrary (weakly) \f$x\f$-monotone segments are presented by a range
* of `X_monotone_curve_2` instances, whose union equals the segment.
* The functor `Construct_x_monotone_segment_2` allows their construction.
* To construct all (maximal) terminal segments of a curve,
@@ -311,34 +310,34 @@ public:
/*! returns the supporting algebraic curve of `s`.
*/
- Curve_2 curve () const;
+ Curve_2 curve() const;
/*! returns whether `s` is a vertical segment.
*/
- bool is_vertical () const;
+ bool is_vertical() const;
/*! returns whether `s` has a finite endpoint on the left
*/
- bool is_finite (CGAL::Arr_curve_end ce) const;
+ bool is_finite(CGAL::Arr_curve_end ce) const;
/*! \pre (The corresponding curve end is finite)
*/
- Point_2 curve_end (CGAL::Arr_curve_end ce) const;
+ Point_2 curve_end(CGAL::Arr_curve_end ce) const;
/*! returns the arc number of the segment.
* \pre (The segment is non-vertical)
*/
- int arcno () const;
+ int arcno() const;
- /*! returns the \f$ x\f$-coordinate of a vertical segment.
+ /*! returns the \f$x\f$-coordinate of a vertical segment.
+ *
* \pre (The segment is vertical)
*/
- Algebraic_real_1 x () const;
+ Algebraic_real_1 x() const;
/// @}
}; /* end Arr_algebraic_segment_traits_2::X_monotone_curve_2 */
-
}; /* end Arr_algebraic_segment_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_batched_point_location.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_batched_point_location.h
index d71d0f7faf9..3ced6434b63 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_batched_point_location.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_batched_point_location.h
@@ -30,9 +30,8 @@ namespace CGAL {
*/
template
-OutputIterator locate (const Arrangement_2& arr,
- InputIterator begin,
- InputIterator end,
- OutputIterator oi);
+OutputIterator locate(const Arrangement_2& arr,
+ InputIterator begin, InputIterator end,
+ OutputIterator oi);
} /* namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_bounded_planar_topology_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_bounded_planar_topology_traits_2.h
index 862416a2fa3..6af33ddbfa4 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_bounded_planar_topology_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_bounded_planar_topology_traits_2.h
@@ -10,18 +10,18 @@ namespace CGAL {
* The `Arr_bounded_planar_topology_traits_2` template has two parameters:
*
* - The `GeometryTraits_2` template-parameter should be substituted by
- * a model of the `ArrangementBasicTraits_2` concept. The traits
+ * a model of the `AosBasicTraits_2` concept. The traits
* class defines the types of \f$x\f$-monotone curves and two-dimensional
- * points, namely `ArrangementBasicTraits_2::X_monotone_curve_2` and
- * `ArrangementBasicTraits_2::Point_2`,
+ * points, namely `AosBasicTraits_2::X_monotone_curve_2` and
+ * `AosBasicTraits_2::Point_2`,
* respectively, and supports basic geometric predicates on them.
*
- The `Dcel` template-parameter should be substituted by
- * a class that is a model of the `ArrangementDcel` concept. The
+ * a class that is a model of the `AosDcel` concept. The
* value of this parameter is by default
* `Arr_default_dcel`.
*
*
- * \cgalModels{ArrangementBasicTopologyTraits}
+ * \cgalModels{AosBasicTopologyTraits}
*
* \sa `Arr_default_dcel`
* \sa `CGAL::Arr_geodesic_arc_on_sphere_traits_2`
@@ -62,10 +62,10 @@ public:
/// \name Accessors
/// @{
- /*! obtains the DCEL (const version). */
+ /*! obtains the \dcel (const version). */
const Dcel& dcel() const;
- /*! obtains the DCEL (non-const version). */
+ /*! obtains the \dcel (non-const version). */
Dcel& dcel();
/*! obtains the unbounded face (const version). */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circle_segment_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circle_segment_traits_2.h
index b3a39fc3e07..88b0fc1dc2b 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circle_segment_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circle_segment_traits_2.h
@@ -3,7 +3,7 @@ namespace CGAL {
/*! \ingroup PkgArrangementOnSurface2TraitsClasses
*
* The class `Arr_circle_segment_traits_2` is a model of the
- * `ArrangementTraits_2` concept and can be used to construct and maintain
+ * `AosTraits_2` concept and can be used to construct and maintain
* arrangements of circular arcs and line segments.
*
* The traits class must be instantiated with a geometric kernel, such that the
@@ -11,34 +11,33 @@ namespace CGAL {
* the supporting lines of the line segments are of type `Kernel::Line_2`.
* Thus, the coordinates of the center of supporting circles, and its squared
* radius are of type `Kernel::FT`, which should be an exact rational
- * number-type; similarly, the coefficients of each supporting line \f$ ax + by
- * + c = 0\f$ are also of type `Kernel::FT`. Note however that the intersection
- * point between two such arcs do not have rational coordinates in general. For
- * this reason, we do not require the endpoints of the input arcs and segments
- * to have rational coordinates.
+ * number-type; similarly, the coefficients of each supporting line
+ * \f$ax + by + c = 0\f$ are also of type `Kernel::FT`. Note however that the
+ * intersection point between two such arcs do not have rational coordinates in
+ * general. For this reason, we do not require the endpoints of the input arcs
+ * and segments to have rational coordinates.
*
* The nested `Point_2` type defined by the traits class is therefore
* different than the `Kernel::Point_2` type. Its coordinates are of type
- * `CoordNT`, which an instantiation of `Sqrt_extension` where `NT =
- * ROOT = Kernel::FT`. Moreover, the third and fourth (hidden) template
- * parameters of `Sqrt_extension` are set to `CGAL::Tag_true`, which
- * enables efficient comparison among different extensions.
+ * `CoordNT`, which an instantiation of `Sqrt_extension` where
+ * `NT` = `ROOT` = `Kernel::FT`. Moreover, the third and fourth (hidden)
+ * template parameters of `Sqrt_extension` are set to `CGAL::Tag_true`,
+ * which enables efficient comparison among different extensions.
*
* For more details see the documentation of `Sqrt_extension`.
*
* While `Arr_circle_segment_traits_2` models the concept
- * `ArrangementDirectionalXMonotoneTraits_2`, the implementation of the
+ * `AosDirectionalXMonotoneTraits_2`, the implementation of the
* `Are_mergeable_2` operation does not enforce the input curves to have the
* same direction as a precondition. Moreover, `Arr_circle_segment_traits_2`
* supports the merging of curves of opposite directions.
*
- * \cgalModels{ArrangementTraits_2,ArrangementDirectionalXMonotoneTraits_2}
+ * \cgalModels{AosTraits_2,AosApproximateTraits_2,AosDirectionalXMonotoneTraits_2}
*
*/
template
class Arr_circle_segment_traits_2 {
public:
-
/*! The `Curve_2` class nested within the traits class can represent
* arbitrary circular arcs, full circles and line segments and support their
* construction in various ways. The copy and default constructor as well as
@@ -88,7 +87,7 @@ public:
* center point with rational coordinates and whose squared radius is
* rational, with the given endpoints. The orientation of the arc is the
* same as the orientation of `circ`.
-
+ *
* \pre Both endpoints must lie on the given supporting circle.
*/
Curve_2(const typename Kernel::Circle_2& circ,
@@ -111,9 +110,9 @@ public:
*
* \pre The three points must not be collinear.
*/
- Curve_2 (const typename Kernel::Point_2& source,
- const typename Kernel::Point_2& mid,
- const typename Kernel::Point_2& target);
+ Curve_2(const typename Kernel::Point_2& source,
+ const typename Kernel::Point_2& mid,
+ const typename Kernel::Point_2& target);
/// @}
@@ -162,7 +161,6 @@ public:
typename Kernel::Circle_2 supporting_circle() const;
/// @}
-
}; /* end Arr_circle_segment_traits_2::Curve_2 */
@@ -172,16 +170,13 @@ public:
*/
class Point_2 {
public:
-
/// \name Types
/// @{
- /*! the `Kernel::FT` type.
- */
+ /// the `Kernel::FT` type.
typedef unspecified_type Rational;
- /*! the algebraic number-type.
- */
+ /// the algebraic number-type.
typedef unspecified_type CoordNT;
/// @}
@@ -193,11 +188,11 @@ public:
*/
Point_2();
- /*! creates the point \f$ (x,y)\f$.
+ /*! creates the point \f$(x,y)\f$.
*/
Point_2(const Rational& x, const Rational& y);
- /*! creates the point \f$ (x,y)\f$.
+ /*! creates the point \f$(x,y)\f$.
*/
Point_2(const CoordNT& x, const CoordNT& y);
@@ -206,36 +201,34 @@ public:
/// \name Access Functions
/// @{
- /*! returns the \f$ x\f$-coordinate.
+ /*! returns the \f$x\f$-coordinate.
*/
CoordNT x() const;
- /*! returns the \f$ y\f$-coordinate.
+ /*! returns the \f$y\f$-coordinate.
*/
CoordNT y() const;
/// @}
-
}; /* end Arr_circle_segment_traits_2::Point_2 */
/*! The `X_monotone_curve_2` class nested within the traits class can
- * represent \f$ x\f$-monotone and line segments (which are always weakly
+ * represent \f$x\f$-monotone and line segments (which are always weakly
* \f$x\f$-monotone). The copy and default constructor as well as the
* assignment operator are provided. In addition, an `operator<<` for the
* curves is defined for standard output streams.
*/
class X_monotone_curve_2 {
public:
-
/// \name Creation
/// @{
/*! constructs an curve corresponding to the line segment directed
* from `source` to `target`, both having rational coordinates.
*/
- X_monotone_curve_2 (const typename Kernel::Point_2& source,
- const typename Kernel::Point_2& target);
+ X_monotone_curve_2(const typename Kernel::Point_2& source,
+ const typename Kernel::Point_2& target);
/*! constructs an curve corresponding to the line segment supported by
* the given line, directed from `source` to `target`. Note that the two
@@ -254,7 +247,7 @@ public:
*
* \pre Both endpoints must lie on the given supporting circle.
*
- * \pre The circular arc is \f$ x\f$-monotone.
+ * \pre The circular arc is \f$x\f$-monotone.
*/
X_monotone_curve_2(const typename Kernel::Circle_2& circ,
const Point_2& source, const Point_2& target,
@@ -275,7 +268,7 @@ public:
/*! returns true if `xcv` is directed right, false otherwise.
*/
- bool is_directed_right () const;
+ bool is_directed_right() const;
/*! returns the left (lexicographically smaller) endpoint of `xcv`.
*/
@@ -292,11 +285,11 @@ public:
/*! determines whether `xcv` is a line segment.
*/
- bool is_linear () const;
+ bool is_linear() const;
/*! determines whether `xcv` is a circular arc.
*/
- bool is_circular () const;
+ bool is_circular() const;
/*! returns the supporting line of `xcv`.
*
@@ -315,7 +308,6 @@ public:
Bbox_2 bbox() const;
/// @}
-
}; /* end Arr_circle_segment_traits_2::X_monotone_curve_2 */
class Trim_2 {
@@ -323,16 +315,15 @@ public:
/// \name Creation
/// @{
- /*! trims the given x-monotone curve to an from src to tgt.
+ /*! trims the given \f$x\f$-monotone curve to an from `src` to `tgt`.
* \ pre `src` and `tgt` lies on the curve
*/
-
X_monotone_curve_2(const X_monotone_curve_2& xcv,
const Point_2& src,
const Point_2& tgt) const
+
/// @}
} /* end Arr_circle_segment_traits_2::Trim_2 */
-
}; /* end Arr_circle_segment_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_arc_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_arc_traits_2.h
index 014e1f5ec21..922b499fff1 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_arc_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_arc_traits_2.h
@@ -1,19 +1,14 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ *
+ * This class is a traits class for \cgal arrangements, built on top of a model
+ * of concept `CircularKernel`.
+ * It provides curves of type `CGAL::Circular_arc_2`.
+ *
+ * \cgalModels{AosTraits_2}
+ */
+template
+class Arr_circular_arc_traits_2 {};
-This class is a traits class for \cgal arrangements, built on top of a model of
-concept `CircularKernel`.
-It provides curves of type `CGAL::Circular_arc_2`.
-
-\cgalModels{ArrangementTraits_2}
-
-*/
-template< typename CircularKernel >
-class Arr_circular_arc_traits_2 {
-public:
-
-}; /* end Arr_circular_arc_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_line_arc_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_line_arc_traits_2.h
index c7bc38001fc..dd280f33fbf 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_line_arc_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_circular_line_arc_traits_2.h
@@ -1,23 +1,17 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ *
+ * This class is a traits class for \cgal arrangements, built on top of a model
+ * of concept `CircularKernel`. It provides curves that can be of both types
+ * `CGAL::Line_arc_2` or `CGAL::Circular_arc_2`.
+ *
+ * It uses the
+ * std::variant.
+ *
+ * \cgalModels{AosTraits_2}
+ */
+template
+class Arr_circular_line_arc_traits_2 {};
-This class is a traits class for \cgal arrangements, built on top of a
-model of concept `CircularKernel`. It provides curves that can be
-of both types
-`CGAL::Line_arc_2` or
-`CGAL::Circular_arc_2`.
-
-It uses the std::variant.
-
-\cgalModels{ArrangementTraits_2}
-
-*/
-template< typename CircularKernel >
-class Arr_circular_line_arc_traits_2 {
-public:
-
-}; /* end Arr_circular_line_arc_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h
index a68feead26c..33a5f127a31 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h
@@ -2,7 +2,7 @@ namespace CGAL {
/*! \ingroup PkgArrangementOnSurface2TraitsClasses
*
- * The class `Arr_conic_traits_2` is a model of the `ArrangementTraits_2`
+ * The class `Arr_conic_traits_2` is a model of the `AosTraits_2`
* concept and can be used to construct and maintain arrangements of bounded
* segments of algebraic curves of degree \f$2\f$ at most, also known as
* conic curves.
@@ -13,13 +13,13 @@ namespace CGAL {
*
*
- * - If \f$4 r s - t^2 > 0\f$, \f$ C\f$ is an ellipse. A special case occurs
- * when \f$r = s\f$ and \f$ t = 0\f$, when \f$ C\f$ becomes a circle.
+ *
- If \f$4 r s - t^2 > 0\f$, \f$C\f$ is an ellipse. A special case occurs
+ * when \f$r = s\f$ and \f$t = 0\f$, when \f$C\f$ becomes a circle.
*
- *
- If \f$4 r s - t^2 < 0\f$, \f$ C\f$ is a hyperbola.
+ *
- If \f$4 r s - t^2 < 0\f$, \f$C\f$ is a hyperbola.
*
- *
- If \f$4 r s - t^2 = 0\f$, \f$ C\f$ is a parabola. A degenerate case
- * occurs when \f$r = s = t = 0\f$, when \f$ C\f$ is a line.
+ *
- If \f$4 r s - t^2 = 0\f$, \f$C\f$ is a parabola. A degenerate case
+ * occurs when \f$r = s = t = 0\f$, when \f$C\f$ is a line.
*
*
*
@@ -27,15 +27,15 @@ namespace CGAL {
*
*
*
- * - A full ellipse (or a circle) \f$ C\f$.
+ *
- A full ellipse (or a circle) \f$C\f$.
*
- *
- The tuple \f$ \langle C, p_s, p_t, o \rangle\f$, where \f$ C\f$ is the
- * supporting conic curve, with the arc endpoints being \f$ p_s\f$ and \f$
- * p_t\f$ (the source and target points, respectively). The orientation \f$ o\f$
- * indicates whether we proceed from \f$ p_s\f$ to \f$ p_t\f$ in a clockwise or
- * in a counterclockwise direction. Note that \f$ C\f$ may also correspond to a
- * line or to pair of lines---in this case \f$ o\f$ may specify a `COLLINEAR`
- * orientation.
+ *
- The tuple \f$\langle C, p_s, p_t, o \rangle\f$, where \f$C\f$ is the
+ * supporting conic curve, with the arc endpoints being \f$p_s\f$ and
+ * \f$p_t\f$ (the source and target points, respectively). The orientation
+ * \f$o\f$ indicates whether we proceed from \f$p_s\f$ to \f$p_t\f$ in a
+ * clockwise or in a counterclockwise direction. Note that \f$C\f$ may also
+ * correspond to a line or to pair of lines---in this case \f$o\f$ may specify a
+ * `COLLINEAR` orientation.
*
*
*
@@ -54,7 +54,7 @@ namespace CGAL {
* must be rational numbers. This guarantees that the coordinates of all
* arrangement vertices (in particular, those representing intersection points)
* are algebraic numbers of degree \f$4\f$ (a real number \f$\alpha\f$ is an
- * algebraic number of degree \f$d\f$ if there exist a polynomial \f$ p\f$ with
+ * algebraic number of degree \f$d\f$ if there exist a polynomial \f$p\f$ with
* integer coefficient of degree \f$d\f$ such that \f$p(\alpha) = 0\f$).
* We therefore require separate representations of the curve
* coefficients and the point coordinates. The `NtTraits` should be substituted
@@ -75,34 +75,31 @@ namespace CGAL {
* and defines a curve and \f$x\f$-monotone curve types, as detailed below.
*
* While the `Arr_conic_traits_2` models the concept
- * `ArrangementDirectionalXMonotoneTraits_2`, the implementation of
+ * `AosDirectionalXMonotoneTraits_2`, the implementation of
* the `Are_mergeable_2` operation does not enforce the input curves
* to have the same direction as a precondition. Moreover, `Arr_conic_traits_2`
* supports the merging of curves of opposite directions.
*
- * \cgalModels{ArrangementTraits_2,ArrangementLandmarkTraits_2,ArrangementDirectionalXMonotoneTraits_2}
+ * \cgalModels{AosTraits_2,AosLandmarkTraits_2,AosApproximateTraits_2,AosDirectionalXMonotoneTraits_2}
*
* \cgalHeading{Types}
*/
template
class Arr_conic_traits_2 {
public:
-
/// \name Types
/// @{
- /*! the `NtTraits::Rational` type (and also the `RatKernel::FT` type).
- */
+ /// the `NtTraits::Rational` type (and also the `RatKernel::FT` type).
typedef unspecified_type Rational;
- /*! the `NtTraits::Algebraic` type (and also the `AlgKernel::FT` type).
- */
+ /// the `NtTraits::Algebraic` type (and also the `AlgKernel::FT` type).
typedef unspecified_type Algebraic;
/// @}
/*! The `Curve_2` class nested within the conic-arc traits can represent
- * arbitrary conic arcs and support their construction in various ways. The
+ * arbitrary conic arcs and support their construction in various ways. The
* copy and default constructor as well as the assignment operator are
* provided for conic arcs. In addition, an `operator<<` for the curves is
* defined for standard output streams.
@@ -211,7 +208,6 @@ public:
void set_target(const Point_2 & pt);
/// @}
-
}; /* end Arr_conic_traits_2::Curve_2 */
/*! \class X_monotone_curve_2
@@ -227,7 +223,6 @@ public:
*/
class X_monotone_curve_2 {
public:
-
/// \name Creation
/// @{
@@ -249,7 +244,6 @@ public:
const Point_2& right() const;
/// @}
-
}; /* end Arr_conic_traits_2::X_monotone_curve_2 */
/*! The `Point_2` class nested within the conic-arc traits is
@@ -366,7 +360,8 @@ public:
* respectively) is available, and their exact locations are given
* implicitly, specified by the intersections of the supporting conic curve
* with \f$r_1 x^2 + s_1 y^2 + t_1 x y + u_1 x + v_1 y + w_1 = 0\f$ and
- * \f$r_2 x^2 + s_2 y^2 + t_2 x y + u_2 x + v_2 y + w_2 = 0\f$, respectively.
+ * \f$r_2 x^2 + s_2 y^2 + t_2 x y + u_2 x + v_2 y + w_2 = 0\f$,
+ * respectively.
*
* \pre The two auxiliary curves specifying the endpoints really intersect
* with the supporting conic curve, such that the arc endpoints define a
@@ -407,11 +402,13 @@ public:
* \pre `source` and `target` must not be the same.
* \return A segment connecting `source` and `target`.
*/
- X_monotone_curve_2 operator()(const Point_2& source, const Point_2& target) const;
+ X_monotone_curve_2 operator()(const Point_2& source,
+ const Point_2& target) const;
/*! constructs a special segment of a given line connecting to given
* endpoints.
- * \param a, b, c The coefficients of the supporting line (\f$ax + by + c = 0\f$).
+ * \param a, b, c The coefficients of the supporting line
+ * (\f$ax + by + c = 0\f$).
* \param source The source point.
* \param target The target point.
* \pre `source` and `target` must not be the same.
@@ -419,7 +416,8 @@ public:
*/
X_monotone_curve_2 operator()(const Algebraic& a, const Algebraic& b,
const Algebraic& c,
- const Point_2& source, const Point_2& target) const;
+ const Point_2& source,
+ const Point_2& target) const;
};
/*! \class Construct_bbox_2
@@ -440,57 +438,14 @@ public:
Bbox_2 operator()(const X_monotone_curve_2& xcv) const { return bbox(xcv); }
};
- /*! \name Auxiliary Functor definitions, used gor, e.g., the landmarks \
+ /*! \name Auxiliary Functor definitions, used for, e.g., the landmarks \
* point-location strategy and the drawing function.
*/
- //@{
+ /// @{
typedef double Approximate_number_type;
typedef CGAL::Cartesian Approximate_kernel;
typedef Approximate_kernel::Point_2 Approximate_point_2;
- //@}
-
- /*! \class Approximate_2
- * A functor that approximates a point and an \f$x\f$-monotone curve.
- */
- class Approximate_2 {
- public:
- /*! obtains an approximation of a point coordinate.
- * \param p The exact point.
- * \param i The coordinate index (either 0 or 1).
- * \pre `i` is either 0 or 1.
- * \return An approximation of p's \f$x\f$-coordinate (if `i` == 0), or an
- * approximation of p's \f$y\f$-coordinate (if `i` == 1).
- */
- Approximate_number_type operator()(const Point_2& p, int i) const;
-
- /*! obtains an approximation of a point.
- * \param p The exact point.
- */
- Approximate_point_2 operator()(const Point_2& p) const;
-
- /*! approximates a given \f$x\f$-monotone curve. It computes a sequence of
- * approximate points that represent an approximate polyline, and inserts
- * them into an output container given through an output iterator. The
- * first and last points in the sequence are always approximations of the
- * endpoints of the given arc.
- *
- * \param oi An output iterator for the output container.
- * \param error The error bound of the polyline approximation. This is the
- * Hausdorff distance between the arc and the polyline that
- * approximates the arc.
- * \param xcv The exact \f$x\f$-monotone arc.
- * \param l2r A Boolean flag that indicates whether the arc direction is
- * left to right.
- * \return The past-the-end iterator of the output container.
- *
- * \pre Dereferencing `oi` must yield an object of type
- * `Arr_conic_traits_2::Approximate_point_2`.
- */
- template
- OutputIterator operator()(OutputIterator oi, double error,
- const X_monotone_curve_2& xcv,
- bool l2r = true) const;
- };
+ /// @}
/*! \class Trim_2
* A functor that trims a conic arc.
@@ -523,11 +478,7 @@ public:
/*! obtains a `Trim_2` functor. */
Trim_2 trim_2_object() const;
- /*! obtains an `Approximate_2` functor. */
- Approximate_2 approximate_2_object() const;
-
/// @}
-
}; /* end Arr_conic_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_consolidated_curve_data_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_consolidated_curve_data_traits_2.h
index c554bc499c2..88e2579512b 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_consolidated_curve_data_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_consolidated_curve_data_traits_2.h
@@ -1,10 +1,9 @@
-
namespace CGAL {
/*! \ingroup PkgArrangementOnSurface2TraitsClasses
*
* The class `Arr_consolidated_curve_data_traits_2` is a model of the concept
- * `ArrangementTraits_2`, and serves as a decorator class that enables the
+ * `AosTraits_2`, and serves as a decorator class that enables the
* extension of the curve type defined by the `Traits` parameter. The traits
* class inherits its point type from `Traits::Point_2`, and defines the types
* `Curve_2` and `X_monotone_curve_2` extended with extraneous data fields of
@@ -12,24 +11,21 @@ namespace CGAL {
*
* Each `Curve_2` object is associated with a single data field of type `Data`,
* and each `X_monotone_curve_2` object is associated with a set of unique data
- * objects. When a curve is subdivided into \f$ x\f$-monotone subcurves, all
+ * objects. When a curve is subdivided into \f$x\f$-monotone subcurves, all
* resulting subcurves are associated with a list containing a single data
- * object, copied from the inducing curve. When an \f$ x\f$-monotone curve is
+ * object, copied from the inducing curve. When an \f$x\f$-monotone curve is
* split, its data set is duplicated, and inserted into the sets of both
- * resulting subcurves. In case two (or more) \f$ x\f$-monotone curves overlap,
- * their data sets are consolidated, and are inserted into the set of the \f$
- * x\f$-monotone curve that represents the overlap.
+ * resulting subcurves. In case two (or more) \f$x\f$-monotone curves overlap,
+ * their data sets are consolidated, and are inserted into the set of the
+ * \f$x\f$-monotone curve that represents the overlap.
*
- * \cgalModels{ArrangementTraits_2}
+ * \cgalModels{AosTraits_2}
*/
template
-class Arr_consolidated_curve_data_traits_2
- : public Arr_curve_data_traits_2,
- _Consolidate_unique_lists,
- Data>
-{
+class Arr_consolidated_curve_data_traits_2 :
+ public Arr_curve_data_traits_2,
+ _Consolidate_unique_lists, Data> {
public:
-
/// \name Types
/// @{
@@ -39,10 +35,10 @@ public:
//! the base curve.
typedef typename Base_traits_2::Curve_2 Base_curve_2;
- //! the base \f$ x\f$-monotone curve curve.
+ //! the base \f$x\f$-monotone curve curve.
typedef typename Base_traits_2::X_monotone_curve_2 Base_x_monotone_curve_2;
- //! a set of data objects that is associated with an \f$ x\f$-monotone curve.
+ //! a set of data objects that is associated with an \f$x\f$-monotone curve.
typedef unspecified_type typedef Data_container;
//! a non-mutable iterator for the data objects in the data container.
@@ -59,14 +55,15 @@ public:
*/
class Data_container {
public:
-
/// \name Creation
/// @{
- /*! constructs default */
+ /*! constructs default.
+ */
Data_container();
- /*! constructs set containing a single `data` object. */
+ /*! constructs set containing a single `data` object.
+ */
Data_container(const Data& data);
/// @}
@@ -74,22 +71,27 @@ public:
/// \name Access Functions
/// @{
- /*! returns the number of data objects in the set. */
+ /*! returns the number of data objects in the set.
+ */
std::size_t size() const;
- /*! returns an iterator pointing to the first data object. */
+ /*! returns an iterator pointing to the first data object.
+ */
Data_iterator begin() const;
- /*! returns a past-the-end iterator for the data objects. */
+ /*! returns a past-the-end iterator for the data objects.
+ */
Data_iterator end() const;
/*! returns the first data object inserted into the set.
- * \pre The number of data objects is not \f$ 0\f$.
+ *
+ * \pre The number of data objects is not \f$0\f$.
*/
const Data& front() const;
/*! returns the last data object inserted into the set.
- * \pre The number of data objects is not \f$ 0\f$.
+ *
+ * \pre The number of data objects is not \f$0\f$.
*/
const Data& back() const;
@@ -123,13 +125,12 @@ public:
*/
bool erase(const Data& data);
- /*! clears the set. */
+ /*! clears the set.
+ */
void clear();
/// @}
-
}; /* end Arr_consolidated_curve_data_traits_2::Data_container */
-
}; /* end Arr_consolidated_curve_data_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_curve_data_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_curve_data_traits_2.h
index c185f3f12fd..2fc70e20c6f 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_curve_data_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_curve_data_traits_2.h
@@ -2,10 +2,10 @@ namespace CGAL {
/*! \ingroup PkgArrangementOnSurface2TraitsClasses
*
- * The class `Arr_curve_data_traits_2` is a model of the `ArrangementTraits_2`
+ * The class `Arr_curve_data_traits_2` is a model of the `AosTraits_2`
* concept and serves as a decorator class that allows the extension of the
- * curves defined by the base traits-class (the `Tr` parameter), which serves as
- * a geometric traits-class (a model of the `ArrangementTraits_2` concept), with
+ * curves defined by the base traits-class (the `Tr` parameter), which serves
+ * as a geometric traits-class (a model of the `AosTraits_2` concept), with
* extraneous (non-geometric) data fields.
*
* The traits class inherits its point type from `Traits::Point_2`, and defines
@@ -13,7 +13,7 @@ namespace CGAL {
*
* Each `Curve_2` object is associated with a single data field of type `CData`,
* and each `X_monotone_curve_2` object is associated with a single data field
- * of type `XData`. When a curve is subdivided into \f$ x\f$-monotone subcurves,
+ * of type `XData`. When a curve is subdivided into \f$x\f$-monotone subcurves,
* its data field is converted using the conversion functor, which is specified
* by the `Cnv` template-parameter, and the resulting objects is copied to all
* `X_monotone_curve_2` objects induced by this curve. The conversion functor
@@ -24,21 +24,18 @@ namespace CGAL {
* By default, the two data types are the same, so the conversion operator
* is trivial:
*
- * |
- * `CData` =
- * |
- *
- * `XData`
- * |
- * |
- * `Cnv` =
- * |
- *
- * `_Default_convert_functor`
- * |
+ *
+ *
+ * | `CData` = |
+ * `XData` |
+ *
+ *
+ * | `Cnv` = |
+ * `_Default_convert_functor` |
+ *
*
*
- * In case two (or more) \f$ x\f$-monotone curves overlap, their data fields are
+ * In case two (or more) \f$x\f$-monotone curves overlap, their data fields are
* merged to a single field, using the merge functor functor, which is specified
* by the `Mrg` template-parameter. This functor should provide an operator with
* the following prototype:
@@ -46,48 +43,39 @@ namespace CGAL {
* `XData operator() (const XData& d1, const XData& d2) const;`
*
* which returns a single data object that represents the merged data field of
- * `d1` and `d2`. The \f$ x\f$-monotone curve that represents the overlap is
+ * `d1` and `d2`. The \f$x\f$-monotone curve that represents the overlap is
* associated with the output of this functor.
*
- * \cgalModels{ArrangementTraits_2}
+ * \cgalModels{AosTraits_2}
*/
template
class Arr_curve_data_traits_2 : public Tr {
public:
-
/// \name Types
/// @{
- /*! the base traits-class.
- */
+ /// the base traits-class.
typedef Tr Base_traits_2;
- /*! the base curve.
- */
+ /// the base curve.
typedef typename Base_traits_2::Curve_2 Base_curve_2;
- /*! the base \f$ x\f$-monotone curve curve.
- */
+ /// the base \f$x\f$-monotone curve curve.
typedef typename Base_traits_2::X_monotone_curve_2 Base_x_monotone_curve_2;
- /*! the point type.
- */
+ /// the point type.
typedef typename Base_traits_2::Point_2 Point_2;
- /*! the merge functor.
- */
+ /// the merge functor.
typedef Mrg Merge;
- /*! the conversion functor.
- */
+ /// the conversion functor.
typedef Cnv Convert;
- /*! the type of data associated with curves.
- */
+ /// the type of data associated with curves.
typedef CData Curve_data;
- /*! the type of data associated with \f$ x\f$-monotone curves.
- */
+ /// the type of data associated with \f$x\f$-monotone curves.
typedef XData X_monotone_curve_data;
/// @}
@@ -97,7 +85,6 @@ public:
*/
class Curve_2 : public Base_curve_2 {
public:
-
/// \name Creation
/// @{
@@ -129,7 +116,6 @@ public:
void set_data(const Curve_data& data);
/// @}
-
}; /* end Arr_curve_data_traits_2::Curve_2 */
/*! The `X_monotone_curve_2` class nested within the curve-data traits extends
@@ -137,20 +123,19 @@ public:
*/
class X_monotone_curve_2 : public Base_x_monotone_curve_2 {
public:
-
/// \name Creation
/// @{
/*! constructs default */
X_monotone_curve_2();
- /*! constructs an \f$ x\f$-monotone curve from the given `base` curve with
+ /*! constructs an \f$x\f$-monotone curve from the given `base` curve with
* uninitialized data field.
*/
X_monotone_curve_2(const Base_x_monotone_curve_2& base);
- /*! constructs an \f$ x\f$-monotone curve from the given `base` \f$
- * x\f$-monotone curve with an attached `data` field.
+ /*! constructs an \f$x\f$-monotone curve from the given `base`
+ * \f$x\f$-monotone curve with an attached `data` field.
*/
X_monotone_curve_2(const Base_x_monotone_curve_2& base,
const X_monotone_curve_data& data);
@@ -170,9 +155,7 @@ public:
void set_data(const X_monotone_curve_data& data);
/// @}
-
}; /* end Arr_curve_data_traits_2::X_monotone_curve_2 */
-
}; /* end Arr_curve_data_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel.h
index b65f8bf4799..56e4e3c3101 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel.h
@@ -7,8 +7,8 @@ namespace CGAL {
* class templates and other templates. It is parameterized by a geometry
* traits type and optionally by a vertex, halfedge, or face types. By default,
* the `Arr_dcel` class template uses the \link
- * ArrangementBasicTraits_2::Point_2 `Point_2`\endlink and \link
- * ArrangementBasicTraits_2::X_monotone_curve_2 `X_monotone_curve_2`\endlink
+ * AosBasicTraits_2::Point_2 `Point_2`\endlink and \link
+ * AosBasicTraits_2::X_monotone_curve_2 `X_monotone_curve_2`\endlink
* types nested in the traits type to instantiate the vertex and base halfedge
* types, respectively. Thus, by default the \dcel only stores the topological
* incidence relations and the geometric data attached to vertices and
@@ -16,15 +16,15 @@ namespace CGAL {
* overridden. Notice that if the vertex and halfedge types are overridden, the
* traits type is ignored.
*
- * \cgalModels{ArrangementDcelWithRebind}
+ * \cgalModels{AosDcelWithRebind}
*
* \tparam Traits a geometry traits type, which is a model of the
- * `ArrangementBasicTraits_2` concept.
- * \tparam V the vertex type, which is a model of the `ArrangementDcelVertex`
+ * `AosBasicTraits_2` concept.
+ * \tparam V the vertex type, which is a model of the `AosDcelVertex`
* concept.
* \tparam H the halfedge type, which is a model of the
- * `ArrangementDcelHalfedge` concept.
- * \tparam F the face type, which is a model of the `ArrangementDcelFace`
+ * `AosDcelHalfedge` concept.
+ * \tparam F the face type, which is a model of the `AosDcelFace`
* concept.
*
* \sa `Arr_dcel_base`
@@ -33,7 +33,6 @@ template ,
typename H = Arr_halfedge_base,
typename F = Arr_face_base>
-class Arr_dcel : public Arr_dcel_base {
-};
+class Arr_dcel : public Arr_dcel_base {};
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h
index 9fa8f5f4d96..1de87dba728 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h
@@ -1,71 +1,46 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2DCEL
-
-\anchor arr_refarr_dcel_base
-
-The `Arr_dcel_base` class is an important ingredient in the
-definition of \dcel data structures. It serves as a basis class for
-any instance of the `Dcel` template parameter of the
-`Arrangement_2` template. In particular it is the basis class of
-the default `Dcel` template parameter, and the basis class of any
-extended \dcel. The template parameters `V`, `H`, and `F`
-must be instantiated with models of the concepts
-`ArrangementDcelVertex`, `ArrangementDcelHalfedge`,
-and `ArrangementDcelFace` respectively.
-
-\cgalModels{ArrangementDcel}
-
-*/
-template< typename V, typename H, typename F >
+/*! \ingroup PkgArrangementOnSurface2DCEL
+ *
+ * \anchor arr_refarr_dcel_base
+ *
+ * The `Arr_dcel_base` class is an important ingredient in the definition of
+ * \dcel data structures. It serves as a basis class for any instance of the
+ * `Dcel` template parameter of the `Arrangement_2` template. In particular it
+ * is the basis class of the default `Dcel` template parameter, and the basis
+ * class of any extended \dcel. The template parameters `V`, `H`, and `F` must
+ * be instantiated with models of the concepts `AosVertex`, `AosHalfedge`, and
+ * `AosFace` respectively.
+ *
+ * \cgalModels{Aos}
+ */
+template
class Arr_dcel_base {
public:
+ /*! The basic \dcel face type. Serves as a basis class for an extended
+ * face record with auxiliary data fields.
+ *
+ * \cgalModels{AosFace}
+ */
+ class Arr_face_base {};
+ /*! The basic \dcel halfedge type. Serves as a basis class for an extended
+ * halfedge record with auxiliary data fields. The `Curve` parameter is the
+ * type of \f$x\f$-monotone curves associated with the vertices.
+ *
+ * \cgalModels{AosHalfedge}
+ */
+ template
+ class Arr_halfedge_base {};
-/*!
-
-The basic \dcel face type. Serves as a basis class for an extended
-face record with auxiliary data fields.
-
-\cgalModels{ArrangementDcelFace}
-
-*/
-class Arr_face_base {
-
-}; /* end Arr_dcel_base::Arr_face_base */
-
-/*!
-
-
-The basic \dcel halfedge type. Serves as a basis class for an
-extended halfedge record with auxiliary data fields. The `Curve`
-parameter is the type of \f$ x\f$-monotone curves associated with the vertices.
-
-\cgalModels{ArrangementDcelHalfedge}
-
-*/
-template< typename Curve >
-class Arr_halfedge_base {
-
-}; /* end Arr_dcel_base::Arr_halfedge_base */
-
-/*!
-
-
-The basic \dcel vertex type. Serves as a basis class for an extended
-vertex record with auxiliary data fields. The `Point` parameter is
-the type of points associated with the vertices.
-
-\cgalModels{ArrangementDcelVertex}
-
-*/
-template< typename Point >
-class Arr_vertex_base {
-
-}; /* end Arr_dcel_base::Arr_vertex_base */
-
-
+ /*! The basic \dcel vertex type. Serves as a basis class for an extended
+ * vertex record with auxiliary data fields. The `Point` parameter is the
+ * type of points associated with the vertices.
+ *
+ * \cgalModels{AosVertex}
+ */
+ template
+ class Arr_vertex_base {};
}; /* end Arr_dcel_base */
+
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h
index b2dba1ca39e..e0674c72567 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h
@@ -5,17 +5,17 @@ namespace CGAL {
* The default \dcel class used by the `Arrangement_2`,
* `Arr_bounded_planar_topology_traits_2`, `Arr_unb_planar_topology_traits_2`
* class templates and other templates. It is parameterized by a geometry
- * traits type. It uses the \link ArrangementBasicTraits_2::Point_2
- * `Point_2`\endlink and \link ArrangementBasicTraits_2::X_monotone_curve_2
+ * traits type. It uses the \link AosBasicTraits_2::Point_2
+ * `Point_2`\endlink and \link AosBasicTraits_2::X_monotone_curve_2
* `X_monotone_curve_2`\endlink types nested in the traits type to instantiate
* the vertex and base halfedge types, respectively. Thus, by default the \dcel
* only stores the topological incidence relations and the geometric data
* attached to vertices and edges.
*
- * \cgalModels{ArrangementDcelWithRebind}
+ * \cgalModels{AosDcelWithRebind}
*
* \tparam Traits a geometry traits type, which is a model of the
- * `ArrangementBasicTraits_2` concept.
+ * `AosBasicTraits_2` concept.
*
* \sa `Arr_dcel`
* \sa `Arr_dcel_base`
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h
index 5b5677b7458..7b4f4fe7f6a 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h
@@ -1,57 +1,45 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
-\ingroup PkgArrangementOnSurface2Overlay
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ * \ingroup PkgArrangementOnSurface2Overlay
+ *
+ * An instance of `Arr_default_overlay_traits` should be used for overlaying two
+ * arrangements of type `Arrangement` that store no auxiliary data with their
+ * \dcel records, where the resulting overlaid arrangement stores no auxiliary
+ * \dcel data as well. This class simply gives empty implementation for all
+ * traits-class functions.
+ *
+ * \cgalModels{OverlayTraits}
+ *
+ * \sa `overlay`
+ */
+template
+class Arr_default_overlay_traits {};
-An instance of `Arr_default_overlay_traits` should be used for overlaying two arrangements
-of type `Arrangement` that store no auxiliary data with their \dcel records, where the resulting overlaid arrangement stores no auxiliary
-\dcel data as well. This class simply gives empty implementation for all
-traits-class functions.
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ * \ingroup PkgArrangementOnSurface2Overlay
+ *
+ * An instance of `Arr_face_overlay_traits` should be used for overlaying two
+ * arrangements of types `Arr_A` and `Arr_B`, which are instantiated using the
+ * same geometric traits-class and with the \dcel classes `Dcel_A` and `Dcel_B`
+ * respectively, in order to store their overlay in an arrangement of type
+ * `Arr_R`, which is instantiated using a third \dcel class `Dcel_R`. All three
+ * \dcel classes are assumed to be instantiations of the
+ * `Arr_face_extended_dcel` template with types `FaceData_A`, `FaceData_B` and
+ * `FaceData_R`, respectively.
+ *
+ * This class gives empty implementation for all overlay traits-class functions,
+ * except the function that computes the overlay of two faces. In this case, it
+ * uses the functor `OvlFaceData`, which accepts a `FaceData_A` object and a
+ * `FaceData_B` object and computes a corresponding `FaceData_R` object, in
+ * order to set the auxiliary data of the overlay face.
+ *
+ * \cgalModels{OverlayTraits}
+ *
+ * \sa `overlay`
+ * \sa `CGAL::Arr_face_extended_dcel`
+ */
+template
+class Arr_face_overlay_traits {};
-\cgalModels{OverlayTraits}
-
-\sa `overlay`
-
-*/
-template< typename Arrangement >
-class Arr_default_overlay_traits {
-public:
-
-}; /* end Arr_default_overlay_traits */
-} /* end namespace CGAL */
-
-namespace CGAL {
-
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
-\ingroup PkgArrangementOnSurface2Overlay
-
-An instance of `Arr_face_overlay_traits` should be used for overlaying two arrangements
-of types `Arr_A` and `Arr_B`, which are instantiated using the same
-geometric traits-class and with the \dcel classes `Dcel_A` and
-`Dcel_B` respectively, in order to store their overlay in an arrangement
-of type `Arr_R`, which is instantiated using a third \dcel class
-`Dcel_R`. All three \dcel classes are assumed to be instantiations of the
-`Arr_face_extended_dcel` template with types `FaceData_A`,
-`FaceData_B` and `FaceData_R`, respectively.
-
-This class gives empty implementation for all overlay traits-class functions,
-except the function that computes the overlay of two faces. In this case,
-it uses the functor `OvlFaceData`, which accepts a `FaceData_A` object
-and a `FaceData_B` object and computes a corresponding `FaceData_R`
-object, in order to set the auxiliary data of the overlay face.
-
-\cgalModels{OverlayTraits}
-
-\sa `overlay`
-\sa `CGAL::Arr_face_extended_dcel`
-
-*/
-template< typename Arr_A, typename Arr_B, typename Arr_R, typename OvlFaceData >
-class Arr_face_overlay_traits {
-public:
-
-}; /* end Arr_face_overlay_traits */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_enums.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_enums.h
index 9a599f50c75..122054cbcb9 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_enums.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_enums.h
@@ -6,7 +6,7 @@ namespace CGAL {
* \f$x\f$-monotone curve. It is used by models geometry traits concept that
* handle boundary conditions.
*
- * \sa `ArrangementOpenBoundaryTraits_2`
+ * \sa `AosOpenBoundaryTraits_2`
*/
enum Arr_curve_end { ARR_MIN_END, ARR_MAX_END };
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h
index b36aa2a7eb7..4fb8c85916e 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h
@@ -1,246 +1,208 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2DCEL
+/*! \ingroup PkgArrangementOnSurface2DCEL
+ *
+ * The `Arr_extended_dcel` class-template extends the topological-features of
+ * the \dcel namely the vertex, halfedge, and face types. While it is possible
+ * to maintain extra (non-geometric) data with the curves or points of the
+ * arrangement by extending their types respectively, it is also possible to
+ * extend the vertex, halfedge, or face types of the \dcel through
+ * inheritance. As the technique to extend these types is somewhat cumbersome
+ * and difficult for inexperienced users, the `Arr_extended_dcel` class-template
+ * provides a convenient way to do that. Each one of the three features is
+ * extended with a corresponding data type provided as parameters. This class
+ * template is also parameterized with a traits class used to extract default
+ * values for the vertex, halfedge, and face base classes, which are the
+ * remaining three template parameters respectively. The default values follow:
+ *
+ * |
+ *
+ * `V` =
+ * |
+ * `Arr_vertex_base`
+ * |
+ * `H` =
+ * |
+ * `Arr_halfedge_base`
+ * |
+ * `F` =
+ * |
+ * `Arr_face_base`
+ *
+ * | | |
+ *
+ * \cgalModels{AosDcelWithRebind}
+ *
+ * \sa `Arr_dcel_base`
+ */
+template
+class Arr_extended_dcel : public Arr_dcel_base,
+ Arr_extended_halfedge,
+ Arr_extended_face>
+{};
-The `Arr_extended_dcel` class-template extends the topological-features of the \dcel
-namely the vertex, halfedge, and face types. While it is possible to maintain
-extra (non-geometric) data with the curves or points of the arrangement by
-extending their types respectively, it is also possible to extend the vertex,
-halfedge, or face types of the \dcel through inheritance. As the technique to
-extend these types is somewhat cumbersome and difficult for inexperienced
-users, the `Arr_extended_dcel` class-template provides a convenient way to do that.
-Each one of the three features is extended with a corresponding data type
-provided as parameters. This class template is also parameterized with a
-traits class used to extract default values for the vertex, halfedge, and face
-base classes, which are the remaining three template parameters respectively.
-The default values follow:
-
-|
-
-`V` =
- |
-`Arr_vertex_base`
-|
-`H` =
- |
-`Arr_halfedge_base`
-|
-`F` =
- |
-`Arr_face_base`
-
- | | |
-
-\cgalModels{ArrangementDcelWithRebind}
-
-\sa `Arr_dcel_base`
-
-*/
-template< typename Traits, typename VData, typename HData, typename FData, typename V, typename H, typename F >
-class Arr_extended_dcel
- : public Arr_dcel_base,
- Arr_extended_halfedge,
- Arr_extended_face >
-{
-
-}; /* end Arr_extended_dcel */
-} /* end namespace CGAL */
-
-namespace CGAL {
-
-/*!
-\ingroup PkgArrangementOnSurface2DCEL
-
-The `Arr_extended_face` class-template extends the face topological-features of the
-\dcel. It is parameterized by a face base-type `FaceBase` and a data type
-`FData` used to extend the face base-type.
-
-\cgalModels{ArrangementDcelFace}
-
-\sa `Arr_dcel_base`
-
-*/
-template< typename FaceBase, typename FData >
+/*! \ingroup PkgArrangementOnSurface2DCEL
+ *
+ * The `Arr_extended_face` class-template extends the face topological-features
+ * of the \dcel. It is parameterized by a face base-type `FaceBase` and a data
+ * type `FData` used to extend the face base-type.
+ *
+ * \cgalModels{AosDcelFace}
+ *
+ * \sa `Arr_dcel_base`
+ */
+template
class Arr_extended_face : FaceBase {
public:
+ /// \name Creation
+ /// @{
-/// \name Creation
-/// @{
+ /*! assigns `f` with the contents of the `other` vertex.
+ */
+ void assign(const Self & other);
-/*!
-assigns `f` with the contents of the `other` vertex.
-*/
-void assign (const Self & other);
+ /// @}
-/// @}
+ /// \name Access Functions
+ /// @{
-/// \name Access Functions
-/// @{
+ /*! obtains the auxiliary data (a non-const version, returning a reference
+ * to a mutable data object is also available).
+ */
+ const FData & data() const;
-/*!
-obtains the auxiliary data (a non-const version, returning a reference
-to a mutable data object is also available).
-*/
-const FData & data () const;
+ /// @}
-/// @}
+ /// \name Modifiers
+ /// @{
-/// \name Modifiers
-/// @{
-
-/*!
-sets the auxiliary data.
-*/
-void set_data (const FData & data);
-
-/// @}
+ /*! sets the auxiliary data.
+ */
+ void set_data(const FData & data);
+ /// @}
}; /* end Arr_extended_face */
-} /* end namespace CGAL */
-namespace CGAL {
-
-/*!
-\ingroup PkgArrangementOnSurface2DCEL
-
-The `Arr_extended_halfedge` class-template extends the halfedge topological-features of
-the \dcel. It is parameterized by a halfedge base-type `HalfedgeBase`
-and a data type `HData` used to extend the halfedge base-type.
-
-\cgalModels{ArrangementDcelHalfedge}
-
-\sa `Arr_dcel_base`
-
-*/
-template< typename HalfedgeBase, typename HData >
+/*! \ingroup PkgArrangementOnSurface2DCEL
+ *
+ * The `Arr_extended_halfedge` class-template extends the halfedge
+ * topological-features of the \dcel. It is parameterized by a halfedge
+ * base-type `HalfedgeBase` and a data type `HData` used to extend the halfedge
+ * base-type.
+ *
+ * \cgalModels{AosDcelHalfedge}
+ *
+ * \sa `Arr_dcel_base`
+ */
+template
class Arr_extended_halfedge : public HalfedgeBase {
public:
+ /// \name Creation
+ /// @{
-/// \name Creation
-/// @{
+ /*! assigns `he` with the contents of the `other` vertex.
+ */
+ void assign(const Self & other);
-/*!
-assigns `he` with the contents of the `other` vertex.
-*/
-void assign (const Self & other);
+ /// @}
-/// @}
+ /// \name Access Functions
+ /// @{
-/// \name Access Functions
-/// @{
+ /*! obtains the auxiliary data (a non-const version, returning a reference
+ * to a mutable data object is also available).
+ */
+ const HData & data() const;
-/*!
-obtains the auxiliary data (a non-const version, returning a reference
-to a mutable data object is also available).
-*/
-const HData & data () const;
+ /// @}
-/// @}
+ /// \name Modifiers
+ /// @{
-/// \name Modifiers
-/// @{
-
-/*!
-sets the auxiliary data.
-*/
-void set_data (const HData & data);
-
-/// @}
+ /*! sets the auxiliary data.
+ */
+ void set_data(const HData & data);
+ /// @}
}; /* end Arr_extended_halfedge */
-} /* end namespace CGAL */
-namespace CGAL {
-
-/*!
-\ingroup PkgArrangementOnSurface2DCEL
-
-The `Arr_extended_vertex` class-template extends the vertex
-topological-features of the \dcel. It is parameterized by a
-vertex base-type `VertexBase` and a data type `VData` used to extend
-the vertex base-type.
-
-\cgalModels{ArrangementDcelVertex}
-
-\sa `Arr_dcel_base`
-
-*/
-template< typename VertexBase, typename VData >
+/*! \ingroup PkgArrangementOnSurface2DCEL
+ *
+ * The `Arr_extended_vertex` class-template extends the vertex
+ * topological-features of the \dcel. It is parameterized by a
+ * vertex base-type `VertexBase` and a data type `VData` used to extend
+ * the vertex base-type.
+ *
+ * \cgalModels{AosDcelVertex}
+ *
+ * \sa `Arr_dcel_base`
+ */
+template
class Arr_extended_vertex : public VertexBase {
public:
+ /// \name Creation
+ /// @{
-/// \name Creation
-/// @{
+ /*! assigns `v` with the contents of the `other` vertex.
+ */
+ void assign(const Self & other);
-/*!
-assigns `v` with the contents of the `other` vertex.
-*/
-void assign (const Self & other);
+ /// @}
-/// @}
+ /// \name Access Functions
+ /// @{
-/// \name Access Functions
-/// @{
+ /*! obtains the auxiliary data (a non-const version, returning a reference
+ * to a mutable data object is also available).
+ */
+ const VData & data() const;
-/*!
-obtains the auxiliary data (a non-const version, returning a reference
-to a mutable data object is also available).
-*/
-const VData & data () const;
+ /// @}
-/// @}
+ /// \name Modifiers
+ /// @{
-/// \name Modifiers
-/// @{
-
-/*!
-sets the auxiliary data.
-*/
-void set_data (const VData & data);
-
-/// @}
+ /*! sets the auxiliary data.
+ */
+ void set_data(const VData & data);
+ /// @}
}; /* end Arr_extended_vertex */
-} /* end namespace CGAL */
-
-namespace CGAL {
-
-/*!
-\ingroup PkgArrangementOnSurface2DCEL
-
-The `Arr_face_extended_dcel` class-template extends the \dcel face-records, making it
-possible to store extra (non-geometric) data with the arrangement faces.
-The class should be instantiated by an `FData` type which represents the
-extra data stored with each face.
-
-Note that all types of \dcel features (namely vertex, halfedge and face)
-are provided as template parameters. However, by default they are defined
-as follows:
-
-|
-
-`V` =
- |
-`Arr_vertex_base`
-|
-`H` =
- |
-`Arr_halfedge_base`
-|
-`F` =
- |
-`Arr_face_base`
-
- | | |
-
-\cgalModels{ArrangementDcelWithRebind}
-
-\sa `Arr_dcel_base`
-
-*/
-template< typename Traits, typename FData, typename V, typename H, typename F >
-class Arr_face_extended_dcel : public Arr_dcel_base > {
-}; /* end Arr_face_extended_dcel */
+
+/*! \ingroup PkgArrangementOnSurface2DCEL
+ *
+ * The `Arr_face_extended_dcel` class-template extends the \dcel face-records,
+ * making it possible to store extra (non-geometric) data with the arrangement
+ * faces. The class should be instantiated by an `FData` type which represents
+ * the extra data stored with each face.
+ *
+ * Note that all types of \dcel features (namely vertex, halfedge and face)
+ * are provided as template parameters. However, by default they are defined
+ * as follows:
+ *
+ * |
+ *
+ * `V` =
+ * |
+ * `Arr_vertex_base`
+ * |
+ * `H` =
+ * |
+ * `Arr_halfedge_base`
+ * |
+ * `F` =
+ * |
+ * `Arr_face_base`
+ *
+ * | | |
+ *
+ * \cgalModels{AosDcelWithRebind}
+ *
+ * \sa `Arr_dcel_base`
+ */
+template
+class Arr_face_extended_dcel :
+ public Arr_dcel_base> {};
+
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_face_index_map.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_face_index_map.h
index 21f071f4596..7830f8f5a18 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_face_index_map.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_face_index_map.h
@@ -1,69 +1,64 @@
namespace CGAL {
- /*! \ingroup PkgArrangementOnSurface2Ref
- *
- * `Arr_face_index_map` maintains a mapping of face handles of an attached
- * arrangement object to indices (of type `unsigned int`). This class template
- * is a model of the concept `ReadablePropertyMap`. A mapping between face
- * handles and indices enables convenient usage of property-map classes supplied
- * by `boost`. For example, the property-map class templates
- * `boost::vector_property_map`, which is based on `std::vector`, and
- * `boost::iterator_property_map`, which can be used to implement a property map
- * based on a native \CC array, require the user to supply a mapping such as
- * `Arr_face_index_map`.
- *
- * As new faces might be inserted into the attached arrangement, and
- * existing faces might be removed, the notification mechanism is used
- * to dynamically maintain the mapping of face handles to indices.
- *
- * \cgalModels{DefaultConstructible,CopyConstructible,Assignable,ReadablePropertyMap}
- *
- * \sa `Arr_vertex_index_map`
+/*! \ingroup PkgArrangementOnSurface2Ref
+ *
+ * `Arr_face_index_map` maintains a mapping of face handles of an attached
+ * arrangement object to indices (of type `unsigned int`). This class template
+ * is a model of the concept `ReadablePropertyMap`. A mapping between face
+ * handles and indices enables convenient usage of property-map classes supplied
+ * by `boost`. For example, the property-map class templates
+ * `boost::vector_property_map`, which is based on `std::vector`, and
+ * `boost::iterator_property_map`, which can be used to implement a property map
+ * based on a native \CC array, require the user to supply a mapping such as
+ * `Arr_face_index_map`.
+ *
+ * As new faces might be inserted into the attached arrangement, and
+ * existing faces might be removed, the notification mechanism is used
+ * to dynamically maintain the mapping of face handles to indices.
+ *
+ * \cgalModels{DefaultConstructible,CopyConstructible,Assignable,ReadablePropertyMap}
+ *
+ * \sa `Arr_vertex_index_map`
+ */
+template
+class Arr_face_index_map: public Arrangement_::Observer {
+public:
+ /// \name Types
+ /// @{
+
+ /// the type of the attached arrangement.
+ typedef Arrangement_ Arrangement_2;
+
+ typedef typename Arrangement_2::Base_aos Base_aos;
+
+ typedef boost::readable_property_map_tag category;
+
+ typedef unsigned int value_type;
+
+ typedef unsigned int reference;
+
+ typedef Face_handle key_type;
+
+ /// The face handle type.
+ typedef typename Base_aos::Face_handle Face_handle;
+
+ /// The type of mapping of faces to indices.
+ typedef Unique_hash_map Index_map;
+
+ /// @}
+
+ /// \name Creation
+ /// @{
+
+ /*! constructs a map that is unattached to any arrangement instance.
*/
+ Arr_face_index_map();
- template
- class Arr_face_index_map: public Arrangement_::Observer {
- public:
+ /*! constructs a map and attaches it to the given arrangement `arr`.
+ */
+ Arr_face_index_map(Base_aos& arr);
- /// \name Types
- /// @{
-
- /*! the type of the attached arrangement.
- */
- typedef Arrangement_ Arrangement_2;
- typedef typename Arrangement_2::Base_aos Base_aos;
-
- typedef boost::readable_property_map_tag category;
-
- typedef unsigned int value_type;
-
- typedef unsigned int reference;
-
- typedef Face_handle key_type;
-
- /*! The face handle type.
- */
- typedef typename Base_aos::Face_handle Face_handle;
-
- /*! The type of mapping of faces to indices.
- */
- typedef Unique_hash_map Index_map;
-
- /// @}
-
- /// \name Creation
- /// @{
-
- /*! constructs a map that is unattached to any arrangement instance.
- */
- Arr_face_index_map();
-
- /*! constructs a map and attaches it to the given arrangement `arr`.
- */
- Arr_face_index_map(Base_aos& arr);
-
- /// @}
-
- }; /* end Arr_accessor */
+ /// @}
+}; /* end Arr_accessor */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_geodesic_arc_on_sphere_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_geodesic_arc_on_sphere_traits_2.h
index 8c766b7783e..5b1f1c73abf 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_geodesic_arc_on_sphere_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_geodesic_arc_on_sphere_traits_2.h
@@ -1,451 +1,452 @@
namespace CGAL {
- /*! \ingroup PkgArrangementOnSurface2TraitsClasses
- *
- * The traits class `Arr_geodesic_arc_on_sphere_traits_2` is a model of the
- * `ArrangementTraits_2` concept. It enables the construction and
- * maintenance of arrangements of arcs of great circles (also known as
- * geodesic arcs) that lie on the sphere (centered at the origin). Almost
- * all operations on arrangements require a kernel that supports exact
- * predicates. Most operations also require a kernel that supports exact
- * constructions. However, all operations on such arrangements can be
- * computed efficiently, since all calculations are performed with
- * rational arithmetic.
- *
- * There is an analogy between this class of arrangements and the class of
- * planar arrangements induced by linear curves (i.e., segments, rays, and
- * lines), as properties of linear curves in the plane often, but not always,
- * hold for geodesic arcs on the sphere. For example, given any two
- * non-antipodal points on the sphere there exists a unique great circle
- * connecting the two points.
- *
- * We use the following parameterization of the unit sphere \f$S =
- * \phi_S(\Phi)\f$: \f$\Phi = [\alpha, 2\pi + \alpha] \times [-\frac{\pi}{2},
- * \frac{\pi}{2}]\f$, \f$\phi_S(x, y) = (\cos y \cos x, \sin y \cos x, \sin
- * x)\f$, where \f$\alpha = \arctan(X, Y)\f$. By default, \f$X = -1, Y = 0\f$,
- * which implies \f$\alpha = \pi\f$, and a default parameterization \f$\Phi =
- * [-\pi, \pi] \times [-\frac{\pi}{2}, \frac{\pi}{2}]\f$. The equator curve,
- * for example, is given by \f$\gamma(t) = (\pi(2t - 1) + \alpha, 0)\f$, for
- * \f$t \in [0,1]\f$. This parameterization induces two contraction points
- * \f$p_s = (0, 0, -1) = \phi_S(y,-\frac{\pi}{2})\f$ and \f$p_n = (0, 0, 1) =
- * \phi_S(y,\frac{\pi}{2})\f$, referred to as the south and north poles,
- * respectively, and an identification curve \f$\{\phi_S(\pi +
- * \alpha,x)\,|\,-\frac{\pi}{2} \leq v \leq \frac{\pi}{2}\}\f$, as
- * \f$\phi_S(-\pi + \alpha,v) = \phi_S(+\pi + \alpha,v)\f$ for all \f$x\f$
- * (which coincides with the opposite Prime (Greenwich) Meridian when
- * \f$\alpha = \pi\f$). The elements that substitutes the template parameters
- * `X` and `Y` when `Arr_geodesic_arc_on_sphere_traits_2` is
- * instantiated must be integral values that define a not necessarily
- * normalized vector \f$(x,y)\f$ in the \f$xy\f$-plane that bisects the
- * identification curve.
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ *
+ * The traits class `Arr_geodesic_arc_on_sphere_traits_2` is a model of the
+ * `AosTraits_2` concept. It enables the construction and
+ * maintenance of arrangements of arcs of great circles (also known as
+ * geodesic arcs) that lie on the sphere (centered at the origin). Almost
+ * all operations on arrangements require a kernel that supports exact
+ * predicates. Most operations also require a kernel that supports exact
+ * constructions. However, all operations on such arrangements can be
+ * computed efficiently, since all calculations are performed with
+ * rational arithmetic.
+ *
+ * There is an analogy between this class of arrangements and the class of
+ * planar arrangements induced by linear curves (i.e., segments, rays, and
+ * lines), as properties of linear curves in the plane often, but not always,
+ * hold for geodesic arcs on the sphere. For example, given any two
+ * non-antipodal points on the sphere there exists a unique great circle
+ * connecting the two points.
+ *
+ * We use the following parameterization of the unit sphere \f$S =
+ * \phi_S(\Phi)\f$: \f$\Phi = [\alpha, 2\pi + \alpha] \times [-\frac{\pi}{2},
+ * \frac{\pi}{2}]\f$, \f$\phi_S(x, y) = (\cos y \cos x, \sin y \cos x, \sin
+ * x)\f$, where \f$\alpha = \arctan(X, Y)\f$. By default, \f$X = -1, Y = 0\f$,
+ * which implies \f$\alpha = \pi\f$, and a default parameterization \f$\Phi =
+ * [-\pi, \pi] \times [-\frac{\pi}{2}, \frac{\pi}{2}]\f$. The equator curve,
+ * for example, is given by \f$\gamma(t) = (\pi(2t - 1) + \alpha, 0)\f$, for
+ * \f$t \in [0,1]\f$. This parameterization induces two contraction points
+ * \f$p_s = (0, 0, -1) = \phi_S(y,-\frac{\pi}{2})\f$ and \f$p_n = (0, 0, 1) =
+ * \phi_S(y,\frac{\pi}{2})\f$, referred to as the south and north poles,
+ * respectively, and an identification curve \f$\{\phi_S(\pi +
+ * \alpha,x)\,|\,-\frac{\pi}{2} \leq v \leq \frac{\pi}{2}\}\f$, as
+ * \f$\phi_S(-\pi + \alpha,v) = \phi_S(+\pi + \alpha,v)\f$ for all \f$x\f$
+ * (which coincides with the opposite Prime (Greenwich) Meridian when
+ * \f$\alpha = \pi\f$). The elements that substitutes the template parameters
+ * `X` and `Y` when `Arr_geodesic_arc_on_sphere_traits_2` is
+ * instantiated must be integral values that define a not necessarily
+ * normalized vector \f$(x,y)\f$ in the \f$xy\f$-plane that bisects the
+ * identification curve.
- * \cgalModels{ArrangementTraits_2,ArrangementLandmarkTraits_2,ArrangementSphericalBoundaryTraits_2}
+ * \cgalModels{AosTraits_2,AosLandmarkTraits_2,AosApproximateTraits_2,AosSphericalBoundaryTraits_2}
+ */
+template
+class Arr_geodesic_arc_on_sphere_traits_2 {
+public:
+ /*! The `Point_2` class nested within the traits is used to represent a
+ * point on a sphere centered at the origin. The point is in fact a
+ * not-necessarily normalized 3D direction extended with information that
+ * specifies the location of the point pre-image in the parameter space.
+ *
+ * \cgalModels{Assignable,DefaultConstructible,CopyConstructible}
*/
-
- template
- class Arr_geodesic_arc_on_sphere_traits_2 {
+ class Point_2 {
public:
- /*! The `Point_2` class nested within the traits is used to represent a
- * point on a sphere centered at the origin. The point is in fact a
- * not-necessarily normalized 3D direction extended with information that
- * specifies the location of the point pre-image in the parameter space.
- *
- * \cgalModels{Assignable,DefaultConstructible,CopyConstructible}
+ /// \name Enumeration types
+ /// @{
+
+ /*! The location type indicates a location in the parameter space.
*/
- class Point_2 {
- public:
- /// \name Enumeration types
- /// @{
+ enum Location_type {
+ /// Internal to the parameter space.
+ NO_BOUNDARY_LOC = 0,
- /*! The location type indicates a location in the parameter space.
- */
- enum Location_type {
- /// Internal to the parameter space.
- NO_BOUNDARY_LOC = 0,
+ /// The bottom side boundary of the parameter space (the south pole).
+ MIN_BOUNDARY_LOC,
- /// The bottom side boundary of the parameter space (the south pole).
- MIN_BOUNDARY_LOC,
+ /// The identified left and right side boundaries of the parameter space.
+ MID_BOUNDARY_LOC,
- /// The identified left and right side boundaries of the parameter space.
- MID_BOUNDARY_LOC,
-
- /// The top side boundary of the parameter space (the north pole).
- MAX_BOUNDARY_LOC
- };
- /// @}
-
- /// \name Types
- /// @{
- typedef Kernel::Direction_3 Direction_3;
- /// @}
-
- /// \name Creation
- /// @{
-
- /*! constructs a point from a direction and a location.
- * \param[in] dir the direction.
- * \param[in] location indicates the location of the point pre-image
- * in the parameter space.
- */
- Point_2(const Direction_3& dir, Location_type location);
-
- /// @}
-
- /// \name Operations
- /// @{
-
- /*! sets the location of the point pre-image in the parameter space.
- * \param[in] location the updated location of the point pre-image in
- * the parameter space.
- */
- void set_location(Location_type location);
-
- /*! obtains the location of the point.
- * \return the location of the point pre-image in the parameter space.
- */
- Location_type location() const;
-
- /// @}
+ /// The top side boundary of the parameter space (the north pole).
+ MAX_BOUNDARY_LOC
};
+ /// @}
- /*! The `X_monotone_curve_2` class nested within the traits is used to
- * represent an \f$x\f$-monotone geodesic arc on the a sphere centered at
- * the origin. The pre-image of an \f$x\f$-monotone geodesic arc does not
- * intersect the identified left and right sides of the boundary of the
- * parameter space.
- *
- * \cgalModels{Assignable,DefaultConstructible,CopyConstructible}
+ /// \name Types
+ /// @{
+ typedef Kernel::Direction_3 Direction_3;
+ /// @}
+
+ /// \name Creation
+ /// @{
+
+ /*! constructs a point from a direction and a location.
+ * \param[in] dir the direction.
+ * \param[in] location indicates the location of the point pre-image
+ * in the parameter space.
*/
- class X_monotone_curve_2 {
- public:
- /// \name Types
- /// @{
- typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
- /// @}
+ Point_2(const Direction_3& dir, Location_type location);
- /// \name Creation
- /// @{
+ /// @}
- /*! constructs an \f$x\f$-monotone geodesic arc.
- * \param[in] source the source point of the arc.
- * \param[in] target the target point of the arc.
- * \param[in] normal the normal of the plane that contains the arc.
- * \param[in] is_vertical is the arc vertical ?
- * \param[in] is_directed_right is the arc directed from left to right?
- * \param[in] is_full is the arc a full great circle?
- * \param[in] is_degenerate is the arc degenerate (single point)?
- * \param[in] is_empty is the arc empty?
- * \pre Both endpoints lie on the given plane.
- */
- X_monotone_curve_2(const Point_2& source,
- const Point_2& target,
- const Direction_3& normal,
- bool is_vertical,
- bool is_directed_right,
- bool is_full = false,
- bool is_degenerate = false,
- bool is_empty = false);
+ /// \name Operations
+ /// @{
- /*! construct an \f$x\f$-monotone geodesic arc.
- * \param[in] normal the normal of the plane containing the arc.
- * \param[in] source the source-point direction.
- * \param[in] target the target-point direction.
- * \pre Both endpoints lie on the given plane.
- */
- X_monotone_curve_2(const Point_2& source,
- const Point_2& target,
- const Direction_3& normal);
-
- /*! construct a full great-circle.
- * \param[in] point the endpoint of the full great-circle.
- * \param[in] normal the normal of the plane containing the arc.
- * \pre the point lies on the given plane.
- * \pre the point pre-image lies on the identified left and right sides
- * of the boundary of the parameter space.
- */
- X_monotone_curve_2(const Point_2& point,
- const Direction_3& normal);
-
- /// @}
-
- /// \name Operations
- /// @{
-
- /*! sets the source endpoint.
- * \param[in] source the updated source endpoint.
- */
- void set_source(const Point_2& source);
-
- /*! sets the target endpoint.
- * \param[in] target the updated target endpoint.
- */
- void set_target(const Point_2& target);
-
- /*! sets the normal of the underlying plane.
- * \param[in] normal the updated normal of the underlying plane.
- */
- void set_normal(const Direction_3& normal);
-
- /*! sets the flag that indicates whether the arc is vertical.
- * \param[in] flag indicates whether the arc pre-image in the parameter
- * space is vertical.
- */
- void set_is_vertical(bool flag);
-
- /*! sets the flag that indicates whether the direction of the arc
- * pre-image in the parameter space is from left to right.
- * \param flag indicates whether the arc pre-image in the parameter
- * space is from left to right.
- */
- void set_is_directed_right(bool flag);
-
- /*! sets the flag that indicates whether the arc is a full great circle.
- * \param[in] flag indicates whether the arc is a full great circle.
- */
- void set_is_full(bool flag);
-
- /*! sets the flag that indicates whether the arc degenerates to a point.
- * \param[in] flag indicates whether the arc degenerates to a point.
- */
- void set_is_degenerate(bool flag);
-
- /*! sets the flag that indicates whether the arc is empty.
- * \param[in] flag indicates whether the arc is empty.
- */
- void set_is_empty(bool flag);
-
- /*! obtains the source point.
- */
- const Point_2& source() const;
-
- /*! obtains the target point.
- */
- const Point_2& target() const;
-
- /*! obtains the normal to the containing plane.
- */
- const Direction_3& normal() const;
-
- /*! obtains the (lexicographically) left endpoint direction.
- */
- const Point_2& left() const;
-
- /*! obtains the (lexicographically) right endpoint.
- */
- const Point_2& right() const;
-
- /*! determines whether the arc is vertical.
- */
- bool is_vertical() const;
-
- /*! determines whether the arc is directed lexicographically from left to
- * right.
- */
- bool is_directed_right() const;
-
- /*! determines whether the arc is a great circle.
- */
- bool is_full() const;
-
- /*! determines whether the arc is degenerate.
- */
- bool is_degenerate() const;
-
- /*! determines whether the arc is empty. */
- bool is_empty() const;
-
- /*! determines whether the arc is a meridian.
- */
- bool is_meridian() const;
-
- /// @}
- };
-
- /*!
+ /*! sets the location of the point pre-image in the parameter space.
+ * \param[in] location the updated location of the point pre-image in
+ * the parameter space.
*/
- class Curve_2 {
- public:
- /// \name Types
- /// @{
- typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
- /// @}
+ void set_location(Location_type location);
- /// \name Creation
- /// @{
- /// @}
-
- /// \name Operations
- /// @{
- /// @}
- };
-
- /*! Construction functor of a point.
- *
- * \cgalModels{Assignable,CopyConstructible,AdaptableUnaryFunction,AdaptableTernaryFunction}
+ /*! obtains the location of the point.
+ * \return the location of the point pre-image in the parameter space.
*/
+ Location_type location() const;
- /*!
- */
- class Construct_point_2 {
- public:
- /// \name Types
- /// @{
- typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 result_type;
- typedef typename Kernel::FT FT;
- typedef typename Kernel::Direction_3 Direction_3;
- /// @}
-
- /// \name Operations
- /// @{
-
- /*! constructs a point on the sphere from three coordinates, which define
- * a (not necessarily normalized) direction.
- * \param[in] x the x coordinate
- * \param[in] y the y coordinate
- * \param[in] z the z coordinate
- */
- Point_2 operator()(const FT& x, const FT& y, const FT& z);
-
- /*! constructs a point on the sphere from a (not necessarily normalized)
- * direction.
- * \param other the other direction
- */
- Point_2 operator()(const Direction_3& other);
-
- /// @}
- };
-
- /*! Construction functor of \f$x\f$-monotone geodesic arcs.
- *
- * \cgalModels{Assignable,CopyConstructible,AdaptableUnaryFunction,AdaptableBinaryFunction,AdaptableTernaryFunction}
- */
- class Construct_x_monotone_curve_2 {
- public:
- /// \name Types
- /// @{
- typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
- typedef Arr_geodesic_arc_on_sphere_traits_2::X_monotone_curve_2 result_type;
- typedef Kernel::Direction_3 Direction_3;
- typedef Direction_3 argument_type;
- /// @}
-
- /// \name Operations
- /// @{
-
- /*! constructs the minor geodesic arc from two endpoints. The minor arc
- * is the one with the smaller angle among the two geodesic arcs with
- * the given endpoints.
- * 1. Find out whether the arc is x-monotone.
- * 2. If it is x-monotone,
- * 2.1 Find out whether it is vertical, and
- * 2.2 whether the target is larger than the source (directed right).
- *
- * An arc is vertical, iff
- * 1. one of its endpoint direction pierces a pole, or
- * 2. the projections of the endpoint directions onto the xy-plane coincide.
- * \param[in] p the first endpoint.
- * \param[in] q the second endpoint.
- * \pre p and q must not coincide.
- * \pre p and q cannot be antipodal.
- * \pre The constructed minor arc does not intersect the identification
- * curve in its interior.
- */
- X_monotone_curve_2 operator()(const Point_2& p, const Point_2& q);
-
- /*! constructs a full great circle from a normal to a plane.
- * Observe that the constructed arc has one endpoint that lies on
- * the identification curve. This point is considered both the source and
- * target (and also the left and right) point of the arc.
- * \param normal the normal to the plane containing the great circle.
- * \pre the plane is not vertical.
- */
- X_monotone_curve_2 operator()(const Direction_3& normal);
-
- /*! constructs a geodesic arc from two endpoints and a normal to the plane
- * containing the arc. The two endpoints determine the plane. The normal
- * determines the orientation of the plane and the final arc (whether its
- * the minor arc or the major arc). The right-hand rule can be used
- * to select the appropriate normal.
- * \param[in] p the first endpoint.
- * \param[in] q the second endpoint.
- * \param[in] normal the normal to the oriented plane containing the arc.
- * \pre Both endpoints lie on the given oriented plane.
- * \pre The constructed arc does not intersect the identification curve
- * in its interior.
- */
- X_monotone_curve_2 operator()(const Point_2& p, const Point_2& q,
- const Direction_3& normal);
-
- /// @} /* end of operations */
- };
-
- /*! Construction functor of geodesic arcs.
- *
- * \cgalModels{Assignable,CopyConstructible,AdaptableUnaryFunction,AdaptableBinaryFunction,AdaptableTernaryFunction}
- */
- class Construct_curve_2 {
- public:
- /// \name Types
- /// @{
- typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
- typedef Arr_geodesic_arc_on_sphere_traits_2::Curve_2 result_type;
- typedef Kernel::Direction_3 Direction_3;
- typedef Direction_3 argument_type;
- /// @}
-
- /// \name Operations
- /// @{
-
- /*! constructs a full great circle from a normal to a plane.
- * \param normal the normal to the plane containing the great circle.
- */
- X_monotone_curve_2 operator()(const Direction_3& normal);
-
- /*! constructs the minor geodesic arc from two endpoints. The minor arc
- * is the one with the smaller angle among the two geodesic arcs with
- * the given endpoints.
- * 1. Find out whether the arc is x-monotone.
- * 2. If it is x-monotone,
- * 1. Find out whether it is vertical, and
- * 2. whether the target is larger than the source (directed right).
- *
- * An arc is vertical, iff
- * 1. one of its endpoint direction pierces a pole, or
- * 2. the projections of the endpoint directions onto the xy-plane coincide.
- *
- * \param[in] p the first endpoint.
- * \param[in] q the second endpoint.
- * \pre p and q must not coincide.
- * \pre p and q cannot be antipodal.
- */
- Curve_2 operator()(const Point_2& p, const Point_2& q);
-
- /*! constructs a geodesic arc from two endpoints and a normal to the plane
- * containing the arc. The two endpoints determine the plane. The normal
- * determines the orientation of the plane and the final arc (whether its
- * the minor arc or the major arc). The right-hand rule can be used
- * to select the appropriate normal.
- * \param[in] p the first endpoint.
- * \param[in] q the second endpoint.
- * \param[in] normal the normal to the oriented plane containing the arc.
- * \pre Both endpoints lie on the given oriented plane.
- */
- Curve_2 operator()(const Point_2& p, const Point_2& q,
- const Direction_3& normal);
- /// @}
- };
-
- /*! returns an instance of `Construct_point_2`.
- */
- Construct_point_2 construct_point_2_object() const;
-
- /*! returns an instance of `Construct_x_monotone_curve_2`.
- */
- Construct_x_monotone_curve_2 construct_x_monotone_curve_2_object() const;
-
- /*! returns an instance of `Construct_curve_2`.
- */
- Construct_curve_2 construct_curve_2_object() const;
+ /// @}
};
+ /*! The `X_monotone_curve_2` class nested within the traits is used to
+ * represent an \f$x\f$-monotone geodesic arc on the a sphere centered at
+ * the origin. The pre-image of an \f$x\f$-monotone geodesic arc does not
+ * intersect the identified left and right sides of the boundary of the
+ * parameter space.
+ *
+ * \cgalModels{Assignable,DefaultConstructible,CopyConstructible}
+ */
+ class X_monotone_curve_2 {
+ public:
+ /// \name Types
+ /// @{
+ typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
+ /// @}
+
+ /// \name Creation
+ /// @{
+
+ /*! constructs an \f$x\f$-monotone geodesic arc.
+ * \param[in] source the source point of the arc.
+ * \param[in] target the target point of the arc.
+ * \param[in] normal the normal of the plane that contains the arc.
+ * \param[in] is_vertical is the arc vertical ?
+ * \param[in] is_directed_right is the arc directed from left to right?
+ * \param[in] is_full is the arc a full great circle?
+ * \param[in] is_degenerate is the arc degenerate (single point)?
+ * \param[in] is_empty is the arc empty?
+ *
+ * \pre Both endpoints lie on the given plane.
+ */
+ X_monotone_curve_2(const Point_2& source,
+ const Point_2& target,
+ const Direction_3& normal,
+ bool is_vertical,
+ bool is_directed_right,
+ bool is_full = false,
+ bool is_degenerate = false,
+ bool is_empty = false);
+
+ /*! constructs an \f$x\f$-monotone geodesic arc.
+ * \param[in] normal the normal of the plane containing the arc.
+ * \param[in] source the source-point direction.
+ * \param[in] target the target-point direction.
+ *
+ * \pre Both endpoints lie on the given plane.
+ */
+ X_monotone_curve_2(const Point_2& source,
+ const Point_2& target,
+ const Direction_3& normal);
+
+ /*! constructs a full great-circle.
+ * \param[in] point the endpoint of the full great-circle.
+ * \param[in] normal the normal of the plane containing the arc.
+ *
+ * \pre the point lies on the given plane.
+ * \pre the point pre-image lies on the identified left and right sides
+ * of the boundary of the parameter space.
+ */
+ X_monotone_curve_2(const Point_2& point,
+ const Direction_3& normal);
+
+ /// @}
+
+ /// \name Operations
+ /// @{
+
+ /*! sets the source endpoint.
+ * \param[in] source the updated source endpoint.
+ */
+ void set_source(const Point_2& source);
+
+ /*! sets the target endpoint.
+ * \param[in] target the updated target endpoint.
+ */
+ void set_target(const Point_2& target);
+
+ /*! sets the normal of the underlying plane.
+ * \param[in] normal the updated normal of the underlying plane.
+ */
+ void set_normal(const Direction_3& normal);
+
+ /*! sets the flag that indicates whether the arc is vertical.
+ * \param[in] flag indicates whether the arc pre-image in the parameter
+ * space is vertical.
+ */
+ void set_is_vertical(bool flag);
+
+ /*! sets the flag that indicates whether the direction of the arc
+ * pre-image in the parameter space is from left to right.
+ * \param flag indicates whether the arc pre-image in the parameter
+ * space is from left to right.
+ */
+ void set_is_directed_right(bool flag);
+
+ /*! sets the flag that indicates whether the arc is a full great circle.
+ * \param[in] flag indicates whether the arc is a full great circle.
+ */
+ void set_is_full(bool flag);
+
+ /*! sets the flag that indicates whether the arc degenerates to a point.
+ * \param[in] flag indicates whether the arc degenerates to a point.
+ */
+ void set_is_degenerate(bool flag);
+
+ /*! sets the flag that indicates whether the arc is empty.
+ * \param[in] flag indicates whether the arc is empty.
+ */
+ void set_is_empty(bool flag);
+
+ /*! obtains the source point.
+ */
+ const Point_2& source() const;
+
+ /*! obtains the target point.
+ */
+ const Point_2& target() const;
+
+ /*! obtains the normal to the containing plane.
+ */
+ const Direction_3& normal() const;
+
+ /*! obtains the (lexicographically) left endpoint direction.
+ */
+ const Point_2& left() const;
+
+ /*! obtains the (lexicographically) right endpoint.
+ */
+ const Point_2& right() const;
+
+ /*! Determines whether the arc is vertical.
+ */
+ bool is_vertical() const;
+
+ /*! determines whether the arc is directed lexicographically from left to right.
+ */
+ bool is_directed_right() const;
+
+ /*! determines whether the arc is a great circle.
+ */
+ bool is_full() const;
+
+ /*! determines whether the arc is degenerate.
+ */
+ bool is_degenerate() const;
+
+ /*! determines whether the arc is empty. */
+ bool is_empty() const;
+
+ /*! determines whether the arc is a meridian.
+ */
+ bool is_meridian() const;
+
+ /// @}
+ };
+
+ /*!
+ */
+ class Curve_2 {
+ public:
+ /// \name Types
+ /// @{
+ typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
+ /// @}
+
+ /// \name Creation
+ /// @{
+ /// @}
+
+ /// \name Operations
+ /// @{
+ /// @}
+ };
+
+ /*! Construction functor of a point.
+ *
+ * \cgalModels{Assignable,CopyConstructible,AdaptableUnaryFunction,AdaptableTernaryFunction}
+ */
+ /*!
+ */
+ class Construct_point_2 {
+ public:
+ /// \name Types
+ /// @{
+ typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 result_type;
+ typedef typename Kernel::FT FT;
+ typedef typename Kernel::Direction_3 Direction_3;
+ /// @}
+
+ /// \name Operations
+ /// @{
+
+ /*! constructs a point on the sphere from three coordinates, which define
+ * a (not necessarily normalized) direction.
+ * \param[in] x the x coordinate
+ * \param[in] y the y coordinate
+ * \param[in] z the z coordinate
+ */
+ Point_2 operator()(const FT& x, const FT& y, const FT& z);
+
+ /*! constructs a point on the sphere from a (not necessarily normalized)
+ * direction.
+ * \param other the other direction
+ */
+ Point_2 operator()(const Direction_3& other);
+
+ /// @}
+ };
+
+ /*! Construction functor of \f$x\f$-monotone geodesic arcs.
+ *
+ * \cgalModels{Assignable,CopyConstructible,AdaptableUnaryFunction,AdaptableBinaryFunction,AdaptableTernaryFunction}
+ */
+ class Construct_x_monotone_curve_2 {
+ public:
+ /// \name Types
+ /// @{
+ typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
+ typedef Arr_geodesic_arc_on_sphere_traits_2::X_monotone_curve_2 result_type;
+ typedef Kernel::Direction_3 Direction_3;
+ typedef Direction_3 argument_type;
+ /// @}
+
+ /// \name Operations
+ /// @{
+
+ /*! constructs the minor geodesic arc from two endpoints. The minor arc
+ * is the one with the smaller angle among the two geodesic arcs with
+ * the given endpoints.
+ * 1. Find out whether the arc is \f$x\f$-monotone.
+ * 2. If it is \f$x\f$-monotone,
+ * 2.1 Find out whether it is vertical, and
+ * 2.2 whether the target is larger than the source (directed right).
+ *
+ * An arc is vertical, iff
+ * 1. one of its endpoint direction pierces a pole, or
+ * 2. the projections of the endpoint directions onto the \f$xy\f$-plane coincide.
+ * \param[in] p the first endpoint.
+ * \param[in] q the second endpoint.
+ * \pre p and q must not coincide.
+ * \pre p and q cannot be antipodal.
+ * \pre The constructed minor arc does not intersect the identification
+ * curve in its interior.
+ */
+ X_monotone_curve_2 operator()(const Point_2& p, const Point_2& q);
+
+ /*! constructs a full great circle from a normal to a plane.
+ * Observe that the constructed arc has one endpoint that lies on
+ * the identification curve. This point is considered both the source and
+ * target (and also the left and right) point of the arc.
+ * \param normal the normal to the plane containing the great circle.
+ * \pre the plane is not vertical.
+ */
+ X_monotone_curve_2 operator()(const Direction_3& normal);
+
+ /*! constructs a geodesic arc from two endpoints and a normal to the plane
+ * containing the arc. The two endpoints determine the plane. The normal
+ * determines the orientation of the plane and the final arc (whether its
+ * the minor arc or the major arc). The right-hand rule can be used
+ * to select the appropriate normal.
+ * \param[in] p the first endpoint.
+ * \param[in] q the second endpoint.
+ * \param[in] normal the normal to the oriented plane containing the arc.
+ * \pre Both endpoints lie on the given oriented plane.
+ * \pre The constructed arc does not intersect the identification curve
+ * in its interior.
+ */
+ X_monotone_curve_2 operator()(const Point_2& p, const Point_2& q,
+ const Direction_3& normal);
+
+ /// @} /* end of operations */
+ };
+
+ /*! Construction functor of geodesic arcs.
+ *
+ * \cgalModels{Assignable,CopyConstructible,AdaptableUnaryFunction,AdaptableBinaryFunction,AdaptableTernaryFunction}
+ */
+ class Construct_curve_2 {
+ public:
+ /// \name Types
+ /// @{
+ typedef Arr_geodesic_arc_on_sphere_traits_2::Point_2 Point_2;
+ typedef Arr_geodesic_arc_on_sphere_traits_2::Curve_2 result_type;
+ typedef Kernel::Direction_3 Direction_3;
+ typedef Direction_3 argument_type;
+ /// @}
+
+ /// \name Operations
+ /// @{
+
+ /*! constructs a full great circle from a normal to a plane.
+ * \param normal the normal to the plane containing the great circle.
+ */
+ X_monotone_curve_2 operator()(const Direction_3& normal);
+
+ /*! constructs the minor geodesic arc from two endpoints. The minor arc
+ * is the one with the smaller angle among the two geodesic arcs with
+ * the given endpoints.
+ * 1. Find out whether the arc is \f$x\f$-monotone.
+ * 2. If it is \f$x\f$-monotone,
+ * 1. Find out whether it is vertical, and
+ * 2. whether the target is larger than the source (directed right).
+ *
+ * An arc is vertical, iff
+ * 1. one of its endpoint direction pierces a pole, or
+ * 2. the projections of the endpoint directions onto the \f$xy\f$-plane coincide.
+ *
+ * \param[in] p the first endpoint.
+ * \param[in] q the second endpoint.
+ * \pre p and q must not coincide.
+ * \pre p and q cannot be antipodal.
+ */
+ Curve_2 operator()(const Point_2& p, const Point_2& q);
+
+ /*! constructs a geodesic arc from two endpoints and a normal to the plane
+ * containing the arc. The two endpoints determine the plane. The normal
+ * determines the orientation of the plane and the final arc (whether its
+ * the minor arc or the major arc). The right-hand rule can be used
+ * to select the appropriate normal.
+ * \param[in] p the first endpoint.
+ * \param[in] q the second endpoint.
+ * \param[in] normal the normal to the oriented plane containing the arc.
+ *
+ * \pre Both endpoints lie on the given oriented plane.
+ */
+ Curve_2 operator()(const Point_2& p, const Point_2& q,
+ const Direction_3& normal);
+ /// @}
+ };
+
+ /*! returns an instance of `Construct_point_2`.
+ */
+ Construct_point_2 construct_point_2_object() const;
+
+ /*! returns an instance of `Construct_x_monotone_curve_2`.
+ */
+ Construct_x_monotone_curve_2 construct_x_monotone_curve_2_object() const;
+
+ /*! returns an instance of `Construct_curve_2`.
+ */
+ Construct_curve_2 construct_curve_2_object() const;
+};
+
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_landmarks_point_location.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_landmarks_point_location.h
index 2567ed62d7c..447b225ab08 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_landmarks_point_location.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_landmarks_point_location.h
@@ -1,62 +1,58 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2PointLocation
+/*! \ingroup PkgArrangementOnSurface2PointLocation
+ *
+ * \anchor arr_reflm_pl
+ *
+ * The `Arr_landmarks_point_location` class implements a Jump & Walk algorithm,
+ * where special points, referred to as "landmarks", are chosen in a
+ * preprocessing stage, their place in the arrangement is found, and they are
+ * inserted into a data-structure that enables efficient nearest-neighbor search
+ * (a Kd-tree). Given a query point, the nearest
+ * landmark is located and a "walk" strategy is applied from the landmark to the
+ * query point.
+ *
+ * There are various strategies to select the landmark set in the
+ * arrangement, where the strategy is determined by the
+ * `Generator` template parameter. The following landmark-generator
+ * classes are available:
+ *
+ * - `Arr_landmarks_vertices_generator`
-
+ * The arrangement vertices are used as the landmarks set.
+ *
+ *
- `Arr_random_landmarks_generator`
-
+ * \f$n\f$ random points in the bounding box of the arrangement are chosen
+ * as the landmarks set.
+ *
+ *
- `Arr_halton_landmarks_generator`
-
+ * \f$n\f$ Halton points in the bounding box of the arrangement are chosen
+ * as the landmarks set.
+ *
+ *
- `Arr_middle_edges_landmarks_generator`
-
+ * The midpoint of each arrangement edge is computed, and the resulting
+ * set of points is used as the landmarks set. This generator can be applied
+ * only for arrangements of line segments.
+ *
+ *
- `Arr_grid_landmarks_generator`
-
+ * A set of \f$n\f$ landmarks are chosen on a
+ * \f$\lceil \sqrt{n} \rceil \times \lceil \sqrt{n} \rceil\f$
+ * grid that covers the bounding box of the arrangement.
+ *
+ * The `Arr_landmarks_vertices_generator` class is the default generator
+ * and used if no `Generator` parameter is specified.
+ *
+ * It is recommended to use the landmarks point-location strategy
+ * when the application frequently issues point-location queries on a
+ * rather static arrangement that the changes applied to it are mainly
+ * insertions of curves and not deletions of them.
+ *
+ * \cgalModels{AosPointLocation_2,AosVerticalRayShoot_2}
+ *
+ * \sa `AosPointLocation_2`
+ * \sa `AosVerticalRayShoot_2`
+ * \sa `CGAL::Arr_point_location_result`
+ */
+template
+class Arr_landmarks_point_location {};
-\anchor arr_reflm_pl
-
-The `Arr_landmarks_point_location` class implements a Jump & Walk algorithm, where special
-points, referred to as "landmarks", are chosen in a preprocessing stage,
-their place in the arrangement is found, and they are inserted into a
-data-structure that enables efficient nearest-neighbor search (a
-Kd-tree). Given a query point, the nearest landmark is located and a
-"walk" strategy is applied from the landmark to the query point.
-
-There are various strategies to select the landmark set in the
-arrangement, where the strategy is determined by the
-`Generator` template parameter. The following landmark-generator
-classes are available:
-
-- `Arr_landmarks_vertices_generator` -
-
-The arrangement vertices are used as the landmarks set.
-
-
- `Arr_random_landmarks_generator` -
-
-\f$ n\f$ random points in the bounding box of the arrangement are chosen
-as the landmarks set.
-
-
- `Arr_halton_landmarks_generator` -
-
-\f$ n\f$ Halton points in the bounding box of the arrangement are chosen
-as the landmarks set.
-
-
- `Arr_middle_edges_landmarks_generator` -
-
-The midpoint of each arrangement edge is computed, and the resulting
-set of points is used as the landmarks set. This generator can be applied
-only for arrangements of line segments.
-
-
- `Arr_grid_landmarks_generator` -
-
-A set of \f$ n\f$ landmarks are chosen on a
-\f$ \lceil \sqrt{n} \rceil \times \lceil \sqrt{n} \rceil\f$
-grid that covers the bounding box of the arrangement.
-
-The `Arr_landmarks_vertices_generator` class is the default generator
-and used if no `Generator` parameter is specified.
-
-It is recommended to use the landmarks point-location strategy
-when the application frequently issues point-location queries on a
-rather static arrangement that the changes applied to it are mainly
-insertions of curves and not deletions of them.
-
-\cgalModels{ArrangementPointLocation_2,ArrangementVerticalRayShoot_2}
-
-\sa `ArrangementPointLocation_2`
-\sa `ArrangementVerticalRayShoot_2`
-\sa `CGAL::Arr_point_location_result`
-
-*/
-template< typename Arrangement, typename Generator >
-class Arr_landmarks_point_location {
-public:
-
-}; /* end Arr_landmarks_point_location */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_line_arc_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_line_arc_traits_2.h
index 909792816a7..78101a83ad7 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_line_arc_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_line_arc_traits_2.h
@@ -1,19 +1,14 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ *
+ * This class is a traits class for \cgal arrangements, built on top of a
+ * model of concept `CircularKernel`. It provides curves of type
+ * `CGAL::Line_arc_2`.
+ *
+ * \cgalModels{AosTraits_2}
+ */
+template
+class Arr_line_arc_traits_2 {};
-This class is a traits class for \cgal arrangements, built on top of a
-model of concept `CircularKernel`. It provides curves of type
-`CGAL::Line_arc_2`.
-
-\cgalModels{ArrangementTraits_2}
-
-*/
-template< typename CircularKernel >
-class Arr_line_arc_traits_2 {
-public:
-
-}; /* end Arr_line_arc_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_linear_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_linear_traits_2.h
index 9a842135e7c..8a26dc62256 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_linear_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_linear_traits_2.h
@@ -3,10 +3,10 @@ namespace CGAL {
/*! \ingroup PkgArrangementOnSurface2TraitsClasses
*
* The traits class `Arr_linear_traits_2` is a model of the
- * `ArrangementTraits_2` concept, which enables the construction and maintenance
+ * `AosTraits_2` concept, which enables the construction and maintenance
* of arrangements of linear objects. The linear objects may be bounded (line
* segments) or unbounded (rays and lines). Thus, it is also a model of the
- * concept `ArrangementOpenBoundaryTraits_2`. The traits class is parameterized
+ * concept `AosOpenBoundaryTraits_2`. The traits class is parameterized
* parameterized with a \cgal-kernel model; see the reference page of
* `Arr_segment_traits_2` for further explanations and recommendations
* on choosing a kernel.
@@ -14,35 +14,34 @@ namespace CGAL {
* `Arr_linear_traits_2` defines `Kernel::Point_2` as its point type. The nested
* `X_monotone_curve_2` and `Curve_2` types defined by the traits class (as is
* the case with the various segment-traits classes, both types refer to the
- * same class, as every linear object is (weakly) \f$ x\f$-monotone), are
+ * same class, as every linear object is (weakly) \f$x\f$-monotone), are
* constructible from a point, a line segment, a ray and from a line (objects of
* types `Kernel::Point_2`, `Kernel::Segment_2`, `Kernel::Ray_2` and
* `Kernel::Line_2`, respectively). On the other hand, when we are given a curve
* we can find out its actual type and convert it to the respective kernel
* object (say, to a `Kernel::Ray_2`).
*
- * \cgalModels{ArrangementTraits_2,ArrangementLandmarkTraits_2,ArrangementOpenBoundaryTraits_2}
+ * \cgalModels{AosTraits_2,AosLandmarkTraits_2,AosOpenBoundaryTraits_2}
*/
template
class Arr_linear_traits_2 {
public:
-
/// \name Types
/// @{
- //!
+ ///
typedef typename Kernel::Segment_2 Segment_2;
- //!
+ ///
typedef typename Kernel::Ray_2 Ray_2;
- //!
+ ///
typedef typename Kernel::Line_2 Line_2;
- //!
+ ///
typedef typename Kernel::Point_2 Point_2;
- //!
+ ///
typedef typename X_monotone_curve_2 Curve_2;
/// @}
@@ -57,20 +56,19 @@ public:
*/
class X_monotone_curve_2 {
public:
-
/// \name Types
/// @{
- //!
+ ///
typedef typename Kernel::Point_2 Point_2;
- //!
+ ///
typedef typename Kernel::Segment_2 Segment_2;
- //!
+ ///
typedef typename Kernel::Ray_2 Ray_2;
- //!
+ ///
typedef typename Kernel::Line_2 Line_2;
/// @}
@@ -139,7 +137,6 @@ public:
Point_2 target() const;
/// @}
-
}; /* end Arr_linear_traits_2::X_monotone_curve_2 */
class Trim_2 {
@@ -147,7 +144,7 @@ public:
/// \name Creation
/// @{
- /*! trims the given x-monotone curve to an from src to tgt.
+ /*! trims the given \f$x\f$-monotone curve to an from `src` to `tgt`.
* \ pre `src` and `tgt` lies on the curve
*/
X_monotone_curve_2 operator()(const X_monotone_curve_2& xcv,
@@ -157,7 +154,6 @@ public:
} /* end Arr_linear_traits_2::Trim_2 */
Trim_2 trim_2_object() const;
-
}; /* end Arr_linear_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_naive_point_location.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_naive_point_location.h
index 8c08d593518..c6f633c7640 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_naive_point_location.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_naive_point_location.h
@@ -1,28 +1,22 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2PointLocation
+/*! \ingroup PkgArrangementOnSurface2PointLocation
+ *
+ * \anchor arr_refnaive_pl
+ *
+ * The `Arr_naive_point_location` class implements a naive algorithm that
+ * traverses all the vertices and halfedges in the arrangement in search for an
+ * answer to a point-location query. The query time is therefore linear in the
+ * complexity of the arrangement. Naturally, this point-location strategy could
+ * turn into a heavy time-consuming process when applied to dense arrangements.
+ *
+ * \cgalModels{AosPointLocation_2,AosVerticalRayShoot_2}
+ *
+ * \sa `AosPointLocation_2`
+ * \sa `AosVerticalRayShoot_2`
+ * \sa `CGAL::Arr_point_location_result`
+ */
+template
+class Arr_naive_point_location {};
-\anchor arr_refnaive_pl
-
-The `Arr_naive_point_location` class implements a naive algorithm that traverses
-all the vertices and halfedges in the arrangement in search for an
-answer to a point-location query.
-The query time is therefore linear in the complexity of the arrangement.
-Naturally, this point-location strategy could turn into a heavy
-time-consuming process when applied to dense arrangements.
-
-\cgalModels{ArrangementPointLocation_2,ArrangementVerticalRayShoot_2}
-
-\sa `ArrangementPointLocation_2`
-\sa `ArrangementVerticalRayShoot_2`
-\sa `CGAL::Arr_point_location_result`
-
-*/
-template< typename Arrangement >
-class Arr_naive_point_location {
-public:
-
-}; /* end Arr_naive_point_location */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_basic_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_basic_traits_2.h
index ab5cf747b7a..9fceee59c5e 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_basic_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_basic_traits_2.h
@@ -1,32 +1,26 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ *
+ * The traits class `Arr_non_caching_segment_basic_traits_2` is a model of the
+ * `AosTraits_2` concept that allow the construction and maintenance of
+ * arrangements of sets of pairwise interior-disjoint line segments. It is
+ * templated with a \cgal-Kernel model, and it is derived from it. This traits
+ * class is a thin layer above the parameterized kernel. It inherits the
+ * `Point_2` from the kernel and its `X_monotone_curve_2` type is defined as
+ * `Kernel::Segment_2`. Most traits-class functor are inherited from the kernel
+ * functor, and the traits class only supplies the necessary functors that are
+ * not provided by the kernel. The kernel is parameterized with a number type,
+ * which should support the arithmetic operations \f$+\f$, \f$-\f$ and
+ * \f$\times\f$ in an exact manner in order to avoid robustness problems. Using
+ * `Cartesian` or `Cartesian` are possible substitutions for the
+ * kernel. Using other (inexact) number types (for example, instantiating the
+ * template with `Simple_cartesian`) is also possible, at the user's own
+ * risk.
+ *
+ * \cgalModels{AosLandmarkTraits_2}
+ */
+template
+class Arr_non_caching_segment_basic_traits_2 {};
-The traits class `Arr_non_caching_segment_basic_traits_2` is a model of the `ArrangementTraits_2`
-concept that allow the construction and maintenance of arrangements of
-sets of pairwise interior-disjoint line segments. It is templated with a
-\cgal-Kernel model, and it is derived from it. This traits class is a
-thin layer above the parameterized kernel. It inherits the `Point_2`
-from the kernel and its `X_monotone_curve_2` type is defined as
-`Kernel::Segment_2`. Most traits-class functor are inherited from the
-kernel functor, and the traits class only supplies the necessary functors
-that are not provided by the kernel. The kernel is parameterized with a
-number type, which should support the arithmetic operations \f$ +\f$, \f$ -\f$ and
-\f$ \times\f$ in an exact manner in order to avoid robustness problems.
-Using `Cartesian` or `Cartesian` are possible
-substitutions for the kernel. Using other (inexact) number types
-(for example, instantiating the template with
-`Simple_cartesian`) is also possible, at the user's own
-risk.
-
-\cgalModels{ArrangementLandmarkTraits_2}
-
-*/
-template< typename Kernel >
-class Arr_non_caching_segment_basic_traits_2 {
-public:
-
-}; /* end Arr_non_caching_segment_basic_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_traits_2.h
index 32a67f5162d..bc5731dfedb 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_traits_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_non_caching_segment_traits_2.h
@@ -1,47 +1,41 @@
-
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2TraitsClasses
+/*! \ingroup PkgArrangementOnSurface2TraitsClasses
+ *
+ * The traits class `Arr_non_caching_segment_traits_2` is a model of the
+ * `AosTraits_2` concept that allows the construction and maintenance of
+ * arrangements of line segments. It is parameterized with a \cgal-Kernel type,
+ * and it is derived from it. This traits class is a thin layer above the
+ * parameterized kernel. It inherits the `Point_2` from the kernel and its
+ * `X_monotone_curve_2` and `Curve_2` types are both defined as
+ * `Kernel::Segment_2`. Most traits-class functor are inherited from the kernel
+ * functor, and the traits class only supplies the necessary functors that are
+ * not provided by the kernel. The kernel is parameterized with a number type,
+ * which should support exact rational arithmetic in order to avoid robustness
+ * problems, although other number types could be used at the user's own risk.
+ *
+ * The traits-class implementation is very simple, yet may lead to a cascaded
+ * representation of intersection points with exponentially long bit-lengths,
+ * especially if the kernel is parameterized with a number type that does not
+ * perform normalization (e.g. `Quotient`). The
+ * `Arr_segment_traits_2` traits class avoids this cascading problem, and should
+ * be the default choice for implementing arrangements of line segments. It is
+ * recommended to use `Arr_non_caching_segment_traits_2` only for very sparse
+ * arrangements of huge sets of input segments.
+ *
+ * While `Arr_non_caching_segment_traits_2` models the concept
+ * `AosDirectionalXMonotoneTraits_2`, the implementation of the
+ * `Are_mergeable_2` operation does not enforce the input curves to have the
+ * same direction as a precondition. Moreover,
+ * `Arr_non_caching_segment_traits_2` supports the merging of curves of opposite
+ * directions.
+ *
+ * \cgalModels{AosTraits_2,AosLandmarkTraits_2,AosDirectionalXMonotoneTraits_2}
+ *
+ * \sa `Arr_segment_traits_2`
+ */
+template
+class Arr_non_caching_segment_traits_2 :
+ public Arr_non_caching_segment_basic_traits_2 {};
-The traits class `Arr_non_caching_segment_traits_2` is a model of the `ArrangementTraits_2`
-concept that allows the construction and maintenance of arrangements of
-line segments. It is parameterized with a \cgal-Kernel type, and it
-is derived from it. This traits class is a thin layer above the
-parameterized kernel. It inherits the `Point_2` from the kernel and its
-`X_monotone_curve_2` and `Curve_2` types are both defined as
-`Kernel::Segment_2`. Most traits-class functor are inherited from the
-kernel functor, and the traits class only supplies the necessary functors
-that are not provided by the kernel. The kernel is parameterized with a
-number type, which should support exact rational arithmetic in order to
-avoid robustness problems, although other number types could be used at the
-user's own risk.
-
-The traits-class implementation is very simple, yet may lead to
-a cascaded representation of intersection points with exponentially long
-bit-lengths, especially if the kernel is parameterized with a number type
-that does not perform normalization (e.g. `Quotient`).
-The `Arr_segment_traits_2` traits class avoids this cascading
-problem, and should be the default choice for implementing arrangements of
-line segments. It is recommended to use `Arr_non_caching_segment_traits_2` only for very sparse
-arrangements of huge sets of input segments.
-
-While `Arr_non_caching_segment_traits_2` models the concept
-`ArrangementDirectionalXMonotoneTraits_2`, the implementation of
-the `Are_mergeable_2` operation does not enforce the input curves
-to have the same direction as a precondition. Moreover, `Arr_non_caching_segment_traits_2`
-supports the merging of curves of opposite directions.
-
-\cgalModels{ArrangementTraits_2,ArrangementLandmarkTraits_2,ArrangementDirectionalXMonotoneTraits_2}
-
-\sa `Arr_segment_traits_2`
-
-*/
-template< typename Kernel >
-class Arr_non_caching_segment_traits_2
- : public Arr_non_caching_segment_basic_traits_2
- {
-public:
-
-}; /* end Arr_non_caching_segment_traits_2 */
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h
index 731c735675a..0efe5184b87 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h
@@ -1,75 +1,72 @@
namespace CGAL {
-/*!
-\ingroup PkgArrangementOnSurface2Funcs
-\brief Computes the overlay of two arrangements `arr1` and `arr2`, and sets
-the output arrangement `res` to represent the overlaid arrangement.
+/*! \ingroup PkgArrangementOnSurface2Funcs
+ * \brief Computes the overlay of two arrangements `arr1` and `arr2`, and sets
+ * the output arrangement `res` to represent the overlaid arrangement.
+ *
+ * \details
+ * Computes the overlay of two input arrangement
+ * objects, and returns the overlaid arrangement. All three arrangements
+ * can be instantiated with different geometric traits classes and different
+ * \dcel classes (encapsulated in the various topology-traits classes).
+ * The geometry traits of the resulting arrangement is used to construct the
+ * resulting arrangement. This means that all the types (e.g.,
+ * `Traits::Point_2`, `Traits::Curve_2`, and `Traits::Point_2`)
+ * of both input arrangements have to be convertible to the types in the
+ * resulting arrangement. A given overlay-traits object is used to properly
+ * construct the overlaid \dcel that represents the resulting arrangement.
+ *
+ * \pre `res` does not refer to either `arr1` or `arr2` (that is,
+ * "self overlay" is not supported).
+ *
+ * \pre The overlay-traits object `ovl_tr` must model the `OverlayTraits`
+ * concept, which is able to construct records of the `ResDcel` class on
+ * the basis of the `Dcel1` and `Dcel2` records that induce them.
+ *
+ * \sa `OverlayTraits`
+ */
+template
+void overlay(const Arrangement_2& arr1,
+ const Arrangement_2& arr2,
+ Arrangement_2& arr_res,
+ OverlayTraits& ovl_tr);
-\details
-Computes the overlay of two input arrangement
-objects, and returns the overlaid arrangement. All three arrangements
-can be instantiated with different geometric traits classes and different
-\dcel classes (encapsulated in the various topology-traits classes).
-The geometry traits of the resulting arrangement is used to construct the
-resulting arrangement. This means that all the types (e.g.,
-`Traits::Point_2`, `Traits::Curve_2`, and `Traits::Point_2`)
-of both input arrangements have to be convertible to the types in the
-resulting arrangement. A given overlay-traits object is used to properly
-construct the overlaid \dcel that represents the resulting arrangement.
-
-\pre `res` does not refer to either `arr1` or `arr2` (that is, "self overlay" is not supported).
-
-\pre The overlay-traits object `ovl_tr` must model the `OverlayTraits`
- concept, which is able to construct records of the `ResDcel` class on
- the basis of the `Dcel1` and `Dcel2` records that induce them.
-
-\sa `OverlayTraits`
-*/
-template
-void overlay (const Arrangement_2& arr1,
- const Arrangement_2& arr2,
- Arrangement_2& arr_res,
- OverlayTraits& ovl_tr);
-
-/*!
-\ingroup PkgArrangementOnSurface2Funcs
-\brief Computes the overlay of two arrangements with history `arr1` and
-`arr2`, and sets the output arrangement with history `res` to
-represent the overlaid arrangement. The function also constructs a
-consolidated set of curves that induce `res`.
-
-\details
-Computes the overlay of two input arrangement
-objects, and returns the overlaid arrangement. All three arrangements
-can be instantiated with different geometric traits classes and different
-\dcel classes (encapsulated in the various topology-traits classes).
-The geometry traits of the resulting arrangement is used to construct the
-resulting arrangement. This means that all the types (e.g.,
-`Traits::Point_2`, `Traits::Curve_2`, and `Traits::Point_2`)
-of both input arrangements have to be convertible to the types in the
-resulting arrangement. A given overlay-traits object is used to properly
-construct the overlaid \dcel that represents the resulting arrangement.
-
-\pre `res` does not refer to either `arr1` or `arr2` (that is, "self overlay" is not supported).
-
-\pre The overlay-traits object `ovl_tr` must model the `OverlayTraits`
- concept, which is able to construct records of the `ResDcel` class on
- the basis of the `Dcel1` and `Dcel2` records that induce them.
-
-\sa `OverlayTraits`
-
-*/
-template
-void overlay (const Arrangement_with_history_2& arr1,
- const Arrangement_with_history_2& arr2,
- Arrangement_with_history_2& res,
- OverlayTraits& ovl_tr);
-
-
-
+void overlay(const Arrangement_with_history_2& arr1,
+ const Arrangement_with_history_2& arr2,
+ Arrangement_with_history_2& res,
+ OverlayTraits& ovl_tr);
} /* end namespace CGAL */
diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_point_location_result.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_point_location_result.h
index 0456c4e06f8..d426218d2fe 100644
--- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_point_location_result.h
+++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_point_location_result.h
@@ -8,16 +8,15 @@ namespace CGAL {
* \tparam Arrangement must be an instance of the
* `CGAL::Arrangement_on_surface_2` class template.
*
- * \sa `ArrangementPointLocation_2`
- * \sa `ArrangementVerticalRayShoot_2`
+ * \sa `AosPointLocation_2`
+ * \sa `AosVerticalRayShoot_2`
* \sa `CGAL::Arr_naive_point_location`
* \sa `CGAL::Arr_walk_along_line_point_location`
* \sa `CGAL::Arr_landmarks_point_location`
* \sa `CGAL::Arr_trapezoid_ric_point_location`
*/
template