pprepair generates lots of spikes (dangling edges)

[lucasmation]

Upon testing the output of pprepair on the Brasilian Enumeration districts we noticed a lot of spikes (or dangling edges) are generated. By comparing the perimeter lenghts before and after pprepair we noticed large perimeter changes are quite common and a lot of them are related to spikes.

See example we posted in this StackOverflow question

The behavior is a bit weird. From reading the paper describing pprepair, I expected small spikes to occur, only inside the overlap areas between original polygons. What we get are large spikes, that follow neighbor polygons perimeters, and excede the original polygon overlap or gap.

Following the suggestion in the StackOverflow question, we tried using the function ST_SimplifyVW to remove the spikes.We first used ST_SimplifyVW(geom_ppr , 0 ) to only remove spikes that were actually lines. This removes only a small fraction of the spikes. Higher tresholds ( ST_SimplifyVW(geom_ppr,1) , ST_SimplifyVW(geom_ppr,5) , ST_SimplifyVW(geom_ppr,10) ) were necessary to remove most of the spikes. The fact that spikes have a non zero area may be due to the errors introduced when importing pprepair output to postgis, due to limited precision in Postgis (double).

It would be great if you could introduce in the pprepair workflow something equivalent to what ST_SimplifyVW(geom_ppr , 0) does.

[hugoledoux]

This spike was surely caused by your choice of a (in this case wrong) repair option. What option did you use?

I assume that above the polygon there are 2 polygons and the spike is a gap between the two, right? Then if you use a longest-boundary repair that spike will disappear; the gap will be filled with either the above-left or above-right polygon.

We do not plan to add simplification of polygons in pprepair, that would break its original idea as the geometries would be moved, and would conflict with other polygons.

[lucasmation]

We used the dafault , I think: "pprepair-new -r fix"

[hugoledoux]

“-r fix” is indeed random neighbour.

put “-r LB” instead, the spike should disappear.

On Wed, Jan 20, 2016 at 5:12 PM, lucasmation notifications@github.com wrote:

We used the dafault , I think: "pprepair-new -r fix"

— Reply to this email directly or view it on GitHub https://github.com/tudelft3d/pprepair/issues/36#issuecomment-173253260.

[lucasmation]

Yeah, I was reading that now. Let me try it out

[lucasmation]

Besides the "-fix" default, is there any other ways in which pprepair-new is behind pprepair (master) that I should be concerned about ?

[hugoledoux]

Don't think so no..

On Wednesday, 20 January 2016, lucasmation notifications@github.com wrote:

Besides the "-fix" default, is there any other ways in which pprepair-new is behind pprepair (master) that I should be concerned about ?

— Reply to this email directly or view it on GitHub https://github.com/tudelft3d/pprepair/issues/36#issuecomment-173266597.

[lucasmation]

@hugoledoux, tks. I tryed with the -r LB and ran the tests again. There are still spikes, although their frequency descreased by one order of magnintude.

For instance, out of 316k sectors we have, :

Sectors whose perimeter changes more than 1%: LB : 1617 RN: 11645

Sectors whose perimeter changes more than 5%: LB : 900 RN: 7040

Still there are quite a number of spikes. Looking at some examples, they still seem similtar to the one in the original stackoverflow question, and they don´t seem related to any "legit" corrections in the polygons.

even with "pprepair-new -r LB" is the RN still being used as default second criteria?

[hugoledoux]

Can you send one isolated example please of such a spike?

And yes random is used is there's a tie. But you'd see it in output if that happened (rare in practice): std::cout << "Reparing 'ties'..." << std::endl;

[lucasmation]

Here is an example of a selection of polygons whose area changed by more than 1%. There are actually 3 polygons with this problem in this area:

the original polygons look like this (I have moved them around in qgis to check for any visible overlaps but found none):

One question: when there is a tie, is the polygon alocated:

a) randomly among the neighbors with the longest border or b) randomly amog any of the neighbors

?

[hugoledoux]

if you could isolate with 4-5 polygons and send them to me that would be useful. Here on screen I can't really assess.

b) is the answer. Indeed, a) would make more sense, open an issue I can work on that at some points. But does the code print "Repairing 'tie'" often for your datasets?

[lucasmation]

The 3 problematic polygons in the image above image are:

blue one: cd_geocodi=530010805100231 yellow one: cd_geocodi=530010805100324 marron one: cd_geocodi=530010805110184 The polygons above are from state 53 (Federal District). I uploaded the data from that state to dropbox here I included: a) original polygons: 53SEE250GC_SIR.shp b) output of prepair-improvments-with-org : pr_53SEE250GC_SIR.shp c) output of pprepair-new -f LB : pr_53SEE250GC_SIR.r.shp (this is the one with the spikes)

you can select the polygons in the picture by the cd_geocodi variable (sorry I did not select the features with the bug. The file is still quite small, I don´t know how to select the features without introducing the postgis changes in precision).

[lucasmation]

and yes, "Repairing 'ties' ..." is printed on the output of pprepair-new for all the 27 state files we are using