Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#10976 closed Bugs (fixed)

Problem with polygon library versions 1.56 and 1.57

Reported by: Uwe Keller <Uwe.Keller@…> Owned by: Andrii Sydorchuk
Milestone: Boost 1.58.0 Component: polygon
Version: Boost 1.56.0 Severity: Problem
Keywords: Cc: Uwe.Keller@…, bjornpiltz@…

Description

It seems that the problem is due to the change of polygon of boost version 1.56. The function is question is

insert_vertex_sequence in polygon_set_data.hpp

In the modified function in version 1.56 the check if the data submitted to the function refer to a hole is missing, as well as the corresponding inversion of the multiplier. Since the attribute is_hole is still present in the argument list of the function I presume that the check was lost. Insertion of this check produces the expected results.

--- snip --------------------------------------------------------------

template <class iT> inline void insert_vertex_sequence(iT begin_vertex, iT end_vertex, direction_1d winding, bool is_hole) {

if (begin_vertex == end_vertex) {

No edges to insert. return;

} Current edge endpoints. iT vertex0 = begin_vertex; iT vertex1 = begin_vertex; if (++vertex1 == end_vertex) {

No edges to insert. return;

} int wmultiplier = (winding == COUNTERCLOCKWISE) ? 1 : -1; if(is_hole) wmultiplier *= -1; <-------------------------patch with respect to 1.55 dirty_ = true; unsorted_ = true; while (vertex0 != end_vertex) {

point_type p0, p1; assign(p0, *vertex0); assign(p1, *vertex1); if (p0 != p1) {

int hmultiplier = (p0.get(HORIZONTAL) == p1.get(HORIZONTAL)) ? -1 : 1; element_type elem(edge_type(p0, p1), hmultiplier * wmultiplier); insert_clean(elem);

} ++vertex0; ++vertex1; if (vertex1 == end_vertex) {

vertex1 = begin_vertex;

}

}

}

--- snap --------------------------------------------------------------

Change History (7)

comment:1 by Uwe Keller <Uwe.Keller@…>, 8 years ago

Hi Luke, tried to contact you by email but it bounced back. So I chode this way, regards, Uwe.

comment:2 by Andrii Sydorchuk, 8 years ago

Owner: changed from Lucanus Simonson to Andrii Sydorchuk

comment:3 by Björn Piltz <bjornpiltz@…>, 8 years ago

Cc: bjornpiltz@… added

comment:4 by Andrii Sydorchuk, 8 years ago

Hi Uwe,

Thank you for your report. Indeed, the regression was introduced in Boost 1.56. I applied the fix and going to add unit tests to cover the issue. The fix will be merged into release branch of Boost 1.58.

comment:5 by Andrii Sydorchuk, 8 years ago

The fix with the corresponding test was pushed to the develop branch.

Last edited 8 years ago by Andrii Sydorchuk (previous) (diff)

comment:6 by Andrii Sydorchuk, 8 years ago

Resolution: fixed
Status: newclosed

The fix was pushed to the master branch.

comment:7 by mhilferink@…, 7 years ago

Note that insert_vertex_sequence() calls insert_clean(elem) which has is_hole as a second optional parameter and already has code to reverse the orientation. It would be cleaner to pass is_hole to insert_clean and avoid scattering the orientation logic around.

BTW, why is on various places the orientation reversed if a edge is horizontal or vertical? I can see that intersected segments can have a reversed order of first and second point due to round off, making a vertical (S<-N) segment from an (NW->SE) edge, or a (S->N) segment from a (SE<-NW) edge. But reversing on specific directions such as in validate_scan, independent of whether point order did change or the points were actually swapped, seems something that is attempted to be compensated elsewhere, such as in _processEvent.

Note: See TracTickets for help on using tickets.