tudelft3d / pprepair

Validation and Automatic Repair of Planar Partitions
GNU General Public License v3.0
57 stars 22 forks source link

poygons disapear after pprepair #28

Closed lucasmation closed 8 years ago

lucasmation commented 8 years ago

We have been running "post pprepair tests" on the pprepaired files of Brazilian Enumeration districts. Because of our instalation and linux version problems, I'm only running tests on the "pprepaired" files that @kenohori sent me (states of CE, PA and BA) .

36 polygons of enumeration districts in the original file disappeared after pprepair. In this link, I include a list of the cd_geocodi identifiers of those polygons here:

https://www.dropbox.com/s/n8przr4lhhwynuk/missing_polygons.csv?dl=0

28 out of the 36 missing polygons were originally "triangles", i.e., polygons formed by 4 vertices. The remaning 8 are much more complex and larger polygons.

I also include pictures of the polygons, before and after pprepair here:

https://www.dropbox.com/s/4gphw59uio8nvsb/images_of_missing_polygons_before_and_after.7z?dl=0

hugoledoux commented 8 years ago

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.

kenohori commented 8 years ago

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 notifications@github.com 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: https://github.com/tudelft3d/pprepair/issues/28#issuecomment-145444759

lucasmation commented 8 years ago

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.

kenohori commented 8 years ago

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

lucasmation commented 8 years ago

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

RobertoLazarte commented 8 years ago

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 ?

kenohori commented 8 years ago

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.

lucasmation commented 8 years ago

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.

lucasmation commented 8 years ago

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