mirror of https://github.com/CGAL/cgal
152 lines
6.0 KiB
Plaintext
152 lines
6.0 KiB
Plaintext
- Documentation
|
|
- Ron suggests to keep the "2D Arrangements" (which is long enough as it
|
|
is, but maybe it should be renamed to "2D Planar Arrangements"), and have
|
|
another chapter on "2D Arrangements on General Surfaces".
|
|
This chapter can be much shorter, as all you can do with arrangements was
|
|
explained and demonstrated in the "2D Arrangements" chapter. We should
|
|
however intorduce the concept of TopologyTraits, and re-interpret the
|
|
functionality of the GeometryTraits.
|
|
|
|
- Incoorporate:
|
|
BasicSweepLineVisitor_2.tex
|
|
Sweep_line_2.tex
|
|
SweepLineVisitor_2.tex
|
|
Basic_sweep_line_2.tex
|
|
Into the documentation
|
|
|
|
- Test RIC trapezoidal point locatoin
|
|
|
|
- Test all landmark sub-strategies
|
|
|
|
- Get rid of the prefix 'get_' from all functions and methods:
|
|
get_bbox
|
|
Bezier_point_2.h,
|
|
Bezier_x_monotone_2.h)
|
|
get_coefficient
|
|
Bezier_cache.h
|
|
Bezier_curve_2.h
|
|
Rational_arc_2.h
|
|
CORE_algebraic_number_traits.h
|
|
get_index
|
|
Arr_circle_segment_traits_2.h
|
|
Arr_conic_traits_2.h
|
|
get_data
|
|
Td_dag.h
|
|
get_level
|
|
Arr_qdx_topology_traits_2_impl.h
|
|
Arr_torus_topology_traits_2_impl.h
|
|
get_lb
|
|
Td_X_trapezoid.h
|
|
Trapezoidal_decomposition_2.h
|
|
get_lt
|
|
Td_X_trapezoid.h
|
|
Trapezoidal_decomposition_2.h
|
|
get_node
|
|
Td_X_trapezoid.h
|
|
Trapezoidal_decomposition_2.h
|
|
get_parent
|
|
Arr_trapezoid_ric_pl_impl.h
|
|
Trapezoidal_decomposition_2.h
|
|
Arr_trapezoid_ric_point_location.h
|
|
get_rb
|
|
Td_X_trapezoid.h
|
|
Trapezoidal_decomposition_2.h
|
|
get_rt
|
|
Td_X_trapezoid.h
|
|
Trapezoidal_decomposition_2.h
|
|
get_depth_threshold
|
|
Trapezoidal_decomposition_2.h
|
|
get_size_threshold
|
|
Trapezoidal_decomposition_2.h
|
|
get_y
|
|
get_double
|
|
Arr_lm_random_generator.h
|
|
Arr_point_location/Arr_lm_random_generator.h
|
|
|
|
- Add insert_* functions back for backward compatibility.
|
|
Keep the old interface for backward complatibility (at least for CGAL 3.4,
|
|
then we can remove it). The "old" functions can just call the "new"
|
|
functions, with a #warning in the code saying that they are deprecated.
|
|
|
|
- Change the interface of Envelope_2 (and Envelope_3):
|
|
to lower_envelope_2 and upper_envelope_2 (lower_envelope_3 and
|
|
upper_envelope_3) and remove lower_envelope_x_monotone_2 and
|
|
upper_envelope_x_monotone_2 (lower_envelope_xy_monotone_3 and
|
|
upper_envelope_xy_monotone_3).
|
|
We can use the value-type of the input iterator to determine which
|
|
operation to perform (just like we do now in insert() ).
|
|
|
|
- Spherical arcs
|
|
- Rewrite the spherical helper class for the vertical-decomposition sweep-
|
|
line visitor (current one is not good enough).
|
|
Regarding the helper class for the spherical case, we currently return the
|
|
"north face" in case we "see" nothing above - which is OK - but we also
|
|
return the "north face" in case we see nothing from *below*. This is wrong:
|
|
we should really keep track of the "south face" and return it as the
|
|
"bottom" object. To conclude, this helper needs more work. It is not top
|
|
priority, but the quick-and-dirty helper that I wrote needs to become a bit
|
|
more complicated ...
|
|
|
|
- The insertion helper and the batched point-location helper seem to have
|
|
been copied from the planar helpers with minor changes. That is, I
|
|
expect to face problem while aggregately inserting new curves into a
|
|
non-empty arrangement on a sphere, or while running a batched
|
|
point-location query on such an arrangement.
|
|
So, there is some work here ... (not much though; these visitors are far
|
|
less complicated than the construction visitor).
|
|
|
|
- The "planar" zone visitor is also used here. I believe this should work,
|
|
as it is generic enough (I hope).
|
|
Can you test it by trying to incrementally insert curves to an
|
|
arrrangement on a sphere.
|
|
|
|
- We can think of adding a test for the spherical topology, similar to the
|
|
construction test developed by Baruch: Namely read n curves from a file,
|
|
construct their arrangement incrementally; construct it aggregately;
|
|
construct an arrangement of n/2 curves then add the rest of the curves;
|
|
construct two arrangement of n/2 curves each and overlay them. In all
|
|
cases, the arrangement dimensions (V, E, F) must be the same ...
|
|
|
|
- Add an example/test for I/O with arrangement of arcs of great circles.
|
|
|
|
- CORE related examples and test fail on the platforms below with a bus error
|
|
- Darwin-8.10_g++-4.0.1_debug
|
|
- powerpc_Darwin-8.10_g++-4.0.1
|
|
|
|
- Arrangement with history is defficient in 2 ways: 1. It restricted to
|
|
curves that do not result with (isolated) vertices, as the interface allows
|
|
a user to obtain the induced edges only. 2. The induced edges of an
|
|
x-monotone curve can be returned to the user in some predetermined order,
|
|
for example left to right, so that the user can exploit it and avoid
|
|
sorting these edges.
|
|
|
|
The first problem can be fixed by either adding another pair of begin/end
|
|
functions that can be used to obtain the range of points, or the current
|
|
pair of begin/end functions can be changed, so that they return a range of
|
|
objects that represent either edges or vertices.
|
|
|
|
The second problem can be fixed by introducing a heirarchy of 2 layers
|
|
to the arrangement with history. The top layer represent the split of
|
|
general curves into x-monotone curves, and the one below represents the
|
|
split at intersection points. As a response to a user request for the items
|
|
induced by a general curve, the range of either edges or points are
|
|
returned in arbitrary order. However, as a response to a user request for
|
|
the edges induced by an x-monote curve, the range of edges are returned in
|
|
order from left to right.
|
|
|
|
In the meantime we could disallow the insertion of curves that contain
|
|
isolated points.
|
|
|
|
- Change insert_point() to point() and keep the former deprecated. Reflect
|
|
the change in the documentation.
|
|
|
|
- Arrangement_on_surface_2 demo
|
|
Cannot change the background color
|
|
|
|
- Boolean_set_operations_2 demo
|
|
Enter a red polygon.
|
|
Enter a blue polygon.
|
|
Perform a Boolean operation.
|
|
Now zoom in, and oops, you see the two input objects again.
|
|
I would expect to zoom into the intersection.
|