poygons disapear after pprepair about pprepair HOT 9 CLOSED

My guess is that pprepair-master was used and run with the option "-d Dissolve the boundaries between regions with the same tag according to the schema index"? @kenohori do you remember?

If that happens when that option is not passed, then it's indeed a bug.

from pprepair.

It was indeed pprepair-master, but without the dissolve function.

I'll try to look into it this weekend.

On Mon, Oct 5, 2015 at 8:51 AM, Hugo Ledoux [email protected]
wrote:

My guess is that pprepair-master was used and run with the option "-d Dissolve the boundaries between regions with the same tag according to the schema index"? @kenohori do you remember?

If that happens when that option is not passed, then it's indeed a bug.

Reply to this email directly or view it on GitHub:
#28 (comment)

from pprepair.

Tks @hugoledoux and @kenohori. Could you then run pprepair-new (discussion at #25 indicated that was the version to use) on those files so we chould use for "post-pprepair" testing on PostGis ? Infact, if it is not to much to ask, could you run pprepair-new on all state files? I ask this because we still having fixed our linux dependencies proplems. Or, alternativelly, could you provide more details on pprepair instalation in Linux, Ubuntu versions, dependencies.

from pprepair.

Here are all the files:
https://www.dropbox.com/sh/tjsbi6cjb5ui95p/AAD8SAE4X5asZ02cKD51bfEsa?dl=0

from pprepair.

@kenohori , I'm back from a 3 week vacation. thank you very much for running pprepair on all files! Roberto, working with me on the project, has already ran checks on this new file. The only state for which we are still having trouble with is MG (minas gerais). 4 setores censitários seem to have disapeared from the MG file. Could you confirm if the MG file was also created by pprepair-new ?

from pprepair.

I'm Roberto and I've been working with Lucas on this project.
I made ​​a mistake about the state with trouble, in reality the state is SP (São Paulo).
In the original shapefile , the SP state (with code 35 ) has 68,296 polygons, while the shapefile repaired by pprepair has 68,291 polygons, five polygons disappeared in the process
The polygons that have disappeared are listed below with their cd_geocodi codes :

351350405000061
351060905000017
353440105000557
354990410000046
351060905000009

What would be the reason for this shapefile has this problem ?

from pprepair.

Hi Roberto,

Sorry for the delay. I've also been on holidays and now preparing to move out of the Netherlands.

The polygons you mention are small and completely overlapping another polygon, so pprepair has to choose one polygon over the other. In this case, the other polygons were selected so they were removed.

from pprepair.

I think you guys should reopen this issue.

Although people making maps make frequent mistakes on borders positions (creating overlaps and gaps), I think it would be unlikely for them to create a polygon by accident. So pprepair should never make a polygon disappear completely.

So I think pprepair should treat differently the polygons that are single triangles to begin with (and also continue to be forme of triangles of the triangulation). It should give them priority when the happen to be overlaping some other polygon.

from pprepair.

@kenohori quick question: what commands did you use to generate the Brasilian Shapefiles in the dropbox-link above?

We now have a working prepair and pprepair instalation on a MAC that seems to work. However, the output shapefiles we produced here also have problems. When we import in postgis and run ST_Union we get an error message. This command works fine with the files you created.

These are the commands we ran:

#prepair
cd ./desktop/setores;
for f in *.shp;
do prepair --ogr $f  --shpOut ./prepair/pr_$f;
done

#pprepair
cd ./prepair;
for f in *.shp;
do pprepair -i $f  -o ./pprepair/ -r fix;  
done

PS: I understand the outputs should be different every time because of random alocaiton of regions. Even then I suppose the getting the ST_Union error or not should not be the result of pure chance.

from pprepair.