- 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 Surface_sweep_2.tex SweepLineVisitor_2.tex Basic_surface_sweep_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_all_inner_nodes() get_bbox() Bezier_point_2.h, Bezier_x_monotone_2.h) get_boundary_in_x() get_boundary_in_y() get_coefficient() Bezier_cache.h Bezier_curve_2.h Rational_arc_2.h CORE_algebraic_number_traits.h get_data() Td_dag.h get_depth_threshold() Trapezoidal_decomposition_2.h get_double() Arr_lm_random_generator.h Arr_point_location/Arr_lm_random_generator.h get_index() Arr_circle_segment_traits_2.h Arr_conic_traits_2.h get_intersections() get_lb() Td_X_trapezoid.h Trapezoidal_decomposition_2.h get_level() Arr_qdx_topology_traits_2_impl.h Arr_torus_topology_traits_2_impl.h get_lt() Td_X_trapezoid.h Trapezoidal_decomposition_2.h get_mode() get_node() Td_X_trapezoid.h Trapezoidal_decomposition_2.h get_originator() get_painter() 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_size_threshold() Trapezoidal_decomposition_2.h get_t_at_x() get_t_at_y() get_traits() get_vertical_tangencies() - 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 - 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 hierarchy 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. - The arrangement demo fails with conics. - There is a warning coming from Cartesian/function_objects.h line 3113 about returning a reference to a temporary variable (which seems to be a good warning; perhaps it is the source of some segmentation faults we encounter). A "kernel expert" should look into this. - In the example dual_lines.cpp we use the function rand(). We should include to avoid a compilation error. - The example circular_line_arcs.cpp does not compile under many platforms, or at least issues warnings about returning a reference to temporary variable. Can you prompt the INRIA people to fix this? (I personally think that we should remove this example from our test-suite, but if the INRIA people believe that it's place is there, they should at least properly maintain it ...) - There is a problem with the examples that use CORE on Darwin (platform #10). Other Darwin platforms seem fine. Do we want to investigate? (perhaps it's just something wrong with the installation ...) - There is a segmentation fault in the examples that use overlay on platforms #10 and #12. Here I don't have a clue ... - There are still some mysterious crashes of the test-suite on some platforms. Again, I don't have a clue ... - compute_intersection_points (InputIterator curves_begin, InputIterator curves_end, OutputIterator points, bool report_endpoints = false, Traits traits = Default_traits()) Allow the traits to be a model of ArrangementXMonotoneTraits_2 and the value type of the input iterator to be X_monotone_curve_2 (and not the general Curve_2). This requires the introduction of a new visitor that does not call the make_x_monotone(). - The callback functions of the observers are const referenced. However, the documentation generator automatically removes the const reference when it generates the cods. The result is very misleading! - The documentation of ParameterSpaceInX_2 and ParameterSpaceInY_2 are missing the requirement for an operator that accepts a point. Is it really needed? Seems like it for isolated points. - _offset_polygon() defined in Approx_offset_base_2.h has a local variable of type kernel. There should be an overloaded function that accepts a kernel as a parameter. - Make the Arr_circle_segment_traits_2 a model of the landmark concept. Need to add 2 required operations, which seems possible. - Support Minkowski sum of a degenerate polygons (using convolution) * A polygon and a point * A polygon and a line Define precisely what type of polygons are valid as summands. - Add non_const_handle(e), where e is an edge handle. - (Nick Simon) Is there a polygon validation method that will tell me if a general polygon with holes is weakly simple or not -- in particular, whether a hole intersects the boundary?