boost::geometry::union_(...) creates redundant closing point

[Volker Schöch <vschoech@…>]

Polygons created by boost::geometry algorithms should conform to the same rules as the input. In the following example, boost::geometry::union_ takes two simple, non-empty rectangular polygons and creates a polygon with a redundant closing point. My polygon type is oriented counter-clockwise and not closed, my point type is based on int.

This is the data used as input to union:

_TPolygon<int> const polygon =
	_TPolygon<int>("MULTIPOLYGON(((3398 1759,3592 1759,3592 1893,3398 1893)))")
	| _TPolygon<int>( "MULTIPOLYGON(((3592 1893,3592 1759,3910 1759,3910 1893)))" );

This is the resulting multi-polygon with the redundant closing point:

MULTIPOLYGON(((3592 1893,3398 1893,3398 1759,3592 1759,3910 1759,3910 1893,3592 1893)))

This is my code that wraps boost::geometry to implement the operator used above:

template<typename T>
template<typename Geometry>
_TPolygon< T > _TPolygon< T >::operator|(Geometry const& geometry) const
{
	_TPolygon< T > polygonOut;
	boost::geometry::union_(*this, geometry, polygonOut);

	// the following line fixes the problem but should not be necessary
	//boost::geometry::correct( polygonOut );

	return polygonOut;
}

[mkaravel]

See attached file ticket_9828.cpp and its output in file ticket_9828.out.

The output polygon is indeed open as you can see from the dsv output of the result, as well as from the number of points that I also print out. The WKT output/description (in develop branch or in the upcoming boost 1.56) "closes" the polygon by default, so it is not a safe way for determining whether polygons are closed or not.

[mkaravel]

stand-along program for reproducing the ticket

[mkaravel]

output of the ticket_9828.cpp program (corrected)