pprepair generates lots of spikes (dangling edges) about pprepair HOT 12 CLOSED

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.

from pprepair.

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

from pprepair.

“-r fix” is indeed random neighbour.

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

On Wed, Jan 20, 2016 at 5:12 PM, lucasmation [email protected]
wrote:

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

—
Reply to this email directly or view it on GitHub
#36 (comment).

from pprepair.

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

from pprepair.

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

from pprepair.

Don't think so no..

On Wednesday, 20 January 2016, lucasmation [email protected] 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
#36 (comment).

from pprepair.

@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?

from pprepair.

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;

from pprepair.

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

?

from pprepair.

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?

from pprepair.

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).

from pprepair.

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

from pprepair.