Dear Boost Geometry,

I wonder if any of you have had time to figure out why the Dissolve.hpp doesn’t compile with version 1.61?

Best regards

Johan

From: Geometry [mailto:geometry-bounces@lists.boost.org] On Behalf Of Johan Doré
Sent: Thursday, May 26, 2016 21:18
To: Boost.Geometry library mailing list <geometry@lists.boost.org>
Subject: [geometry] Dissolve in version 1.61

Dear Boost Geometry,

I just tried to download version 1.61. Unfortunately we are using the Dissolve function, but I cannot find a Branch or Tag in Github with a version of Dissole which compiles with version 1.61.

I wonder if I am looking the wrong places I it simply hasn’t made it yet?

Best regards

Johan

From: Geometry [mailto:geometry-bounces@lists.boost.org] On Behalf Of Johan Doré
Sent: Tuesday, March 22, 2016 13:33
To: Boost.Geometry library mailing list <geometry@lists.boost.org>
Subject: Re: [geometry] Dissolve rescale_policy

Dear Barend and Adam,

Thanks for the update. As always keep up all the good work, it is an incredible daily help.

Best regards

Johan

From: Geometry [mailto:geometry-bounces@lists.boost.org] On Behalf Of Barend Gehrels
Sent: Wednesday, March 16, 2016 16:50
To: Boost.Geometry library mailing list <geometry@lists.boost.org>
Subject: Re: [geometry] Dissolve rescale_policy

Hi,


Op 16-3-2016 om 3:36 schreef Adam Wulkiewicz:

Hi Johan,

Johan Doré wrote:

Dear Boost Geometry

In version 1.60 wonder if there is an reason for the no_rescale_policy in the dissolve function:

Do you mean extensions from develop branch? dissolve() is not a part of the official release, or am I missing something?

<snip>

Changing it to the robust policy:

inline void dissolve(Geometry const& geometry, Collection& output_collection)

{

  concept::check<Geometry const>();

typedef typename boost::range_value<Collection>::type geometry_out;

  concept::check<geometry_out>();

typedef typename geometry::rescale_policy_type

  <

typename geometry::point_type<Geometry>::type

  >::type rescale_policy_type;

  rescale_policy_type robust_policy = geometry::get_rescale_policy<rescale_policy_type>(geometry);

  dispatch::dissolve

  <

typename tag<Geometry>::type,

typename tag<geometry_out>::type,

    Geometry,

    geometry_out

  >::apply(geometry, robust_policy, std::back_inserter(output_collection));

}

Seems to correctly dissolve a larger range of invalid polygons.

I therefore wonder if this change I recommendable and should be included?

There are some problems with rescaling we discovered recently. Functions taking two input geometries rescale both geometries in the same time, functions taking one input geometry rescale only one geometry. In both cases the geometries are rescaled WRT the size of a bounding box of all input geometries (so 2 or 1). So the same geometry may be rescaled differently in both cases depending on a function to which it's passed and e.g. the size of the other geometry if a function takes two geometries. And an interesting things may happen during the rescaling. E.g. the vertices of a geometry may be moved relativelly to each other. So in rare cases some edges detected e.g. as collinear after being rescaled differently may be seen as intersecting which means that, e.g. the output of a set operation may be detected as invalid.

We plan to experiment with a different solution. In a long run I think this change is not a prefered. However the rest of the library use the rescaling for Areal geometries so after applying your change dissolve would be consistent with other algorithms.

Barend what do you think about it?

I agree with Adam's answer. I think currently the rescaling can be included in the dissolve extension, it makes it consistent with the other algorithms and apparently it helps dissolving problematic polygons.

On longer term we hope to remove the rescaling again, indeed.

Note that the new approach (using clusters instead of handling tangencies individually) should also help in the dissolve process, though I did not try it there.

Regards, Barend