tudelft3d / pprepair Goto Github PK

Use the ideas of prepair regarding nesting of constraints

I'm getting a "Segmentation fault: 11", even with the -bd option. Is there any debugging information that can be output to try to solve this issue?

related to issue #25

Is it possible to force to split regions, preserving all regions, and remove "cutoff regions"?

I give an example below for what I want to achieve. The orange polygons here originally came from layer "B" within a CAD file, the green polygon came from layer "A". The green polygons are actually about the same size as the whole complete area with all it's polygons. So the green area polygon is visible there because there is no orange polygon on top of it.

So I want to "cut out" just a green polygon as it's visible in the first picture, and throw away the rest of the green polygon since it is mostly overlapped by orange polygons.

Green and orange:

Only green:

I'm working with Lucas on repairing shape files of the enumeration districts of the Brazilian 2010 Census.

In order to create a shapefile with the errors, we used the option --outerrors, but didn't work in all of our tries.
Using the shape "11SEE250GC_SIR.shp" as example, we ran prepair first to validate the geometries.
Then, we used:

pprepair -i "11SEE250GC_SIR_1.shp" -v --outerrors err.shp

but we are getting the message:
"ERROR 1: TopologyException:Found non-noded intersection between LINESTRING..."

The option --outtr works fine, but for some reason --outerrors always get that error. What should be the right usage in order to output the erros?

First, thanks for this amazing program! We were pulling our hair out trying to solve the topological probems in PostGis.

I'm trying to correct the shape files of the enumeration districts of the Brazilian 2010 Census, about 318k polygons in total, which has lots of topological problems, overlays, gaps, etc. The data is divided by state shapefiles and available from: ftp://geoftp.ibge.gov.br/malhas_digitais/censo_2010/setores_censitarios/

pprepair works great in 19 of the 27 states. However for the remaining 8 states, which have the largest shapefiles, ppreair issues the following error and stops :

"segmentation fault (core dumped)"

This error ocurr after much of the fixes have been completed, at the last step, just when the shapefiles are about to be saved.

For instance, pprepair crashes with the Bahia(BA) data, which has a 57mb shapefile and 24k polygons. The shapefile is available from:

ftp://geoftp.ibge.gov.br/malhas_digitais/censo_2010/setores_censitarios/ba/ba_setores_censitarios.zip

pprepair keeps using more and more RAM. At the time it crasses, in the Bahia case, ppreair is using 3gb of RAM (which is still bellow the available 16gb of ram)

Additionally, a different error ocurrs for the state o Pará (PA) (ftp://geoftp.ibge.gov.br/malhas_digitais/censo_2010/setores_censitarios/pa/pa_setores_censitarios.zip). pprepair seems to never end the computation. Keeps runing indefinetivelly. This is weird as the PA file is only 17mb, not particularly large relative to other states.

We are using:

Ununtu 12.04 LTS, 64bits
RAM: 16GB

Library versions:
"gdal 1.9.0, release 2011/12/29"
"cmake version 2.8.7"
cgal: 3.9-1bulild1

Hello,
I encountered a segmentation fault: 11 when working with a geojson input file with empty properties, {}, as follows:

$ pprepair -i input.json -v
Adding a new set of polygons to the triangulation...
    Path: input.json
    Type: GeoJSON
    Layers: 1
    Reading layer #1 (535 polygons)...
ERROR 1: Invalid index : 0
Segmentation fault: 11
$
$ cat input.json
     :
     :
 "type": "Feature",
 "properties": {},
 "geometry": {
   "type": "Polygon",
   "coordinates": [
     :
     :

It works well when inserting a dummy content into the "properties": {"name": null}, for example.

Hi,
i have a segmentation fault with pprepair under : ubuntu 10.04 + gdal 1.9.0 + libcgal 3.5.1-1. Same result with or without .prj.
Is there anyone meeting the same issue ? or having the solution ?
Sorry, i'm a beginner with this forum and program.

root@ubuntu:/home/administrateur/tudelft-gist-pprepair-c8bab39# ls
CMakeCache.txt definitions FaceInfo.cpp LICENSE.txt PolygonHandle.cpp README.md
CMakeFiles essai_region.prj FaceInfo.h Makefile PolygonHandle.h test
cmake_install.cmake essai_region.shp IOWorker.cpp PlanarPartition.cpp pprepair test_noprj
CMakeLists.txt essai_region.shx IOWorker.h PlanarPartition.h pprepair.cpp

root@ubuntu:/home/administrateur/tudelft-gist-pprepair-c8bab39# ./pprepair -i "essai_region.shp" -o "essai_region_output.shp" -fix
Adding a new set of polygons to the triangulation...
Path: essai_region.shp
Type: ESRI Shapefile
Layers: 1
Reading layer #1 (154705408 polygons)...
Erreur de segmentation

Copying definitions.h to Definitions.h to fix previous issue, and then compiling gives:

$ make -f Makefile.linux
c++ -Wall -O3 -frounding-math -fno-strict-aliasing -I/usr/include/gdal -L/usr/lib -c PolygonHandle.cpp
PolygonHandle.cpp: In member function ‘bool MultiPolygonHandle::hasHandle(PolygonHandle_)’:
PolygonHandle.cpp:242: error: no matching function for call to ‘find(std::List_iterator<PolygonHandle>, std::List_iterator<PolygonHandle*>, PolygonHandle&)’
make: *_* [PolygonHandle.o] Error 1

My C++ skills don't help here, I have no idea...

Ubuntu 10.04

All the other .o files in the Makefile compile okay, example:

$ make PlanarPartition.o
g++ -c -o PlanarPartition.o PlanarPartition.cpp

Using the basic command:
$ ./pprepair -i inputfile -o outputfile -fix
gives in some cases strange results.
For example, I have in my input shapefile those 2 polygons:

And in my output shapefile, I have this result:

Is there a way to solve/avoid this problem?

Hi, I would like to start using pprepair, so I clone your repo installed gdal and cgal. I am using cmake 3.0.2 with a gui, but keep having the same problem:
CMake Error at CMakeLists.txt:42 (message):
pprepair requires the CGAL library
CGAL_DIR-NOTFOUND

I installed the CGAL 4.4 versione and set the env var
CGAL_DIR to the library path.

The cmake output is as follows:
The C compiler identification is MSVC 16.0.40219.1
The CXX compiler identification is MSVC 16.0.40219.1
Check for working C compiler using: Visual Studio 10 2010
Check for working C compiler using: Visual Studio 10 2010 -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler using: Visual Studio 10 2010
Check for working CXX compiler using: Visual Studio 10 2010 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
CMake Error at CMakeLists.txt:42 (message):
pprepair requires the CGAL lib

I can't really understand where the cmake is searching the cgal lib..
can you please help me?
thanks and regards

paolo

Relabel triangle to ensure a minimum robustness

I use pprepair on a small shapefile http://mga.alwaysdata.net/geo/GDB/FSAC_parcelles/
root@debian:/d/web/pprepair# ./pprepair -i FSAC_parcelles.shp -o fixed.shp -fix
Adding a new set of polygons to the triangulation...
Path: /mnt/USB/FSAC_parcelles/FSAC_parcelles.shp
Type: ESRI Shapefile
Layers: 1
Reading layer #1 (25 polygons)...

          string          Colonne1
    Feature #9 (10 vertices): self intersecting outer boundary #0. Split.
    Created 2 rings.
    Feature #11: duplicate vertices in outer boundary #0. Removed duplicates.
    Feature #11: incorrect winding in inner boundary #0. Reversed.
    Feature #11: inner boundary cannot fit in any outer boundary. Skipped.
    Feature #15 (16 vertices): self intersecting outer boundary #0. Split.
    Created 3 rings.
    Feature #16 (10 vertices): self intersecting outer boundary #0. Split.

terminate called after throwing an instance of 'CGAL::Assertion_exception'
what(): CGAL ERROR: assertion violation!
Expr: hcl != NULL
File: /usr/include/CGAL/Constraint_hierarchy_2.h
Line: 576
Abandon
root@debian:

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.

Hi,
First, thank you so much for maintaining pprepair - it is very useful for helping clean-up bad data! I just tried to use it again and I received a Segmentation fault error (11) when running pprepair on my Mac (Yosemite 10.10.3). Dependency versions are as follows:

• CMake 3.2.3
• CGAL 4.6
• GDAL 1.11.2

When installing with CMake, there is an error that I could only assume was due to CGAL 4.6, but installing previous versions of CGAL didn't fix the issue. Maybe it's something to do with the Yosemite update?

Any help would be great. I'm working on setting up a virtual machine so I can maintain a working version of pprepair without worrying about Apple's (or others') updates. Thank you!

Scanning dependencies of target pprepair
[ 20%] Building CXX object CMakeFiles/pprepair.dir/FaceInfo.cpp.o
[ 40%] Building CXX object CMakeFiles/pprepair.dir/IOWorker.cpp.o
In file included from /Users/path/pprepair/IOWorker.cpp:22:
In file included from /Users/path/pprepair/IOWorker.h:26:
In file included from /Users/path/pprepair/definitions/CGALDefinitions.h:42:
In file included from /usr/local/Cellar/cgal/4.6/include/CGAL/Constrained_Delaunay_triangulation_2.h:25:
In file included from /usr/local/Cellar/cgal/4.6/include/CGAL/Constrained_triangulation_2.h:28:
In file included from /usr/local/Cellar/cgal/4.6/include/CGAL/Triangulation_2.h:38:
In file included from /usr/local/Cellar/cgal/4.6/include/CGAL/Triangulation_data_structure_2.h:38:
/usr/local/Cellar/cgal/4.6/include/CGAL/Compact_container.h:1150:13: warning: 
      reference cannot be bound to dereferenced null pointer in well-defined C++
      code; comparison may be assumed to always evaluate to false
      [-Wtautological-undefined-compare]
    return &*rhs == NULL;
            ^~~~    ~~~~
/usr/local/Cellar/cgal/4.6/include/CGAL/Triangulation_data_structure_2.h:697:10: note: 
      in instantiation of function template specialization
      'CGAL::internal::operator==<CGAL::Compact_container<CGAL::Triangulation_face_base_with_info_2<FaceInfo,
      CGAL::Epeck, CGAL::Constrained_triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_ds_face_base_2<CGAL::Triangulation_data_structure_2<CGAL::Triangulation_vertex_base_2<CGAL::Epeck,
      CGAL::Triangulation_ds_vertex_base_2<void> >,
      CGAL::Triangulation_face_base_with_info_2<FaceInfo, CGAL::Epeck,
      CGAL::Constrained_triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_ds_face_base_2<void> > > > > > > > >, CGAL::Default,
      CGAL::Default, CGAL::Default>, false>' requested here
  if (fc == 0) return false;
         ^
/usr/local/Cellar/cgal/4.6/include/CGAL/Triangulation_2.h:894:15: note: in
      instantiation of member function
      'CGAL::Triangulation_data_structure_2<CGAL::Triangulation_vertex_base_2<CGAL::Epeck,
      CGAL::Triangulation_ds_vertex_base_2<void> >,
      CGAL::Triangulation_face_base_with_info_2<FaceInfo, CGAL::Epeck,
      CGAL::Constrained_triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_ds_face_base_2<void> > > > >::is_edge' requested here
  return _tds.is_edge(va, vb, fr, i);
              ^
/Users/path/pprepair/IOWorker.cpp:347:25: note: 
      in instantiation of member function 'CGAL::Triangulation_2<CGAL::Epeck,
      CGAL::Triangulation_data_structure_2<CGAL::Triangulation_vertex_base_2<CGAL::Epeck,
      CGAL::Triangulation_ds_vertex_base_2<void> >,
      CGAL::Triangulation_face_base_with_info_2<FaceInfo, CGAL::Epeck,
      CGAL::Constrained_triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_face_base_2<CGAL::Epeck,
      CGAL::Triangulation_ds_face_base_2<void> > > > > >::is_edge' requested here
                                        if (!triangulation.is_edge(*previ...
                                                           ^
/usr/local/Cellar/cgal/4.6/include/CGAL/Compact_container.h:1095:15: note: 
      'operator*' returns a reference
    reference operator*() const { return *(m_ptr.p); }
              ^
1 warning generated.
[ 60%] Building CXX object CMakeFiles/pprepair.dir/PlanarPartition.cpp.o
[ 80%] Building CXX object CMakeFiles/pprepair.dir/PolygonHandle.cpp.o
[100%] Building CXX object CMakeFiles/pprepair.dir/pprepair.cpp.o
Linking CXX executable pprepair
[100%] Built target pprepair

According to https://github.com/tudelft3d/pprepair/blob/master/README.md#L31, one should specify cmake -DDRIVER="ESRI Shapefile" . , but on

cmake 2.8.8 (default on Redhat) does not include a FindCGAL.cmake module so then it does not work out of the box.

I added:

set(CGAL_DIR /home/martijn/opt/lib/CGAL)
find_package(CGAL REQUIRED)
include_directories(${CGAL_INCLUDE_DIRS})
set(LIBS ${LIBS} ${CGAL_LIBRARIES})

set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} /home/martijn/opt/lib)
INCLUDE_DIRECTORIES(/home/martijn/opt/include)
LINK_DIRECTORIES(/home/martijn/opt/lib)

(as I installed CGAL in my home folder), it then works.

Maybe this can be done by forcing a specific version for cmake, that's what I don't know.

Hello, I have been working with pprepair, and it is doing quite nicely (I call it from R to clean up polygons I am analyzing). So far, it has worked in most cases, but I have one set of test polygons I just came across that is giving me an error.

wget https://dl.dropbox.com/u/31890709/poly_bad.zip
unzip poly_bad.zip
pprepair -i poly_bad.shp -o poly_fix.shp

Adding a new set of polygons to the triangulation...
Path: poly_bad.shp
Type: ESRI Shapefile
Layers: 1
Reading layer #1 (3 polygons)...

  double      dummy
    string      ID
Feature #0 (28 vertices): self intersecting outer boundary #0. Split.

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Abort

Any thoughts on how to fix will be very appreciated.

Thanks!

interested to use this tool, but it crashed badly on the very first test set. Environment is Ubuntu 14.04

pprepair$ valgrind build/pprepair -i /home/shared/test_pprepair/a2.shp -fix -o $WDIR/b2.shp
==6501== Memcheck, a memory error detector
==6501== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6501== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==6501== Command: build/pprepair -i /home/shared/test_pprepair/a2.shp -fix -o /home/shared/test_pprepair/b2.shp
==6501== 
Adding a new set of polygons to the triangulation...
	Path: /home/shared/test_pprepair/a2.shp
	Type: ESRI Shapefile
	Layers: 1
	Reading layer #1 (18 polygons)...
>		int        	gid
		string     	statefp
		string     	countyfp
		string     	cousubfp
		string     	cousubns
		string     	geoid
		string     	name
		string     	namelsad
		string     	lsad
		string     	classfp
		string     	mtfcc
		string     	cnectafp
		string     	nectafp
		string     	nctadvfp
		string     	funcstat
		double     	aland
		double     	awater
		string     	intptlat
		string     	intptlon
Polygons added (8 s). The triangulation has now:
	Vertices: 20547
	Edges: 61638
	Triangles: 41065
Tagging...
Tagging done (1 s).
Input triangulation:
	Holes:    0 triangles (0.000000 %)
	Ok:       41044 triangles (99.948862 %)
	Overlaps: 21 triangles (0.051138 %)
Repairing regions by longest boundary...
Repair successful (0 s). All polygons are now valid.
Triangulation already repaired!
Repaired triangulation:
	Holes:    0 triangles (0.000000 %)
	Ok:       41065 triangles (100.000000 %)
	Overlaps: 0 triangles (0.000000 %)
Reconstructing polygons (geometry)...
	Removed 11 constrained edges
Polygons reconstructed (1 s).
Exporting polygons...
ERROR 1: GeoJSON parsing error: unexpected end of data (at offset 31)
ERROR 4: Failed to read GeoJSON data
	Writing file... 
==6501== Conditional jump or move depends on uninitialised value(s)
==6501==    at 0x5ECE97C: OGRGeoJSONDataSource::ICreateLayer(char const*, OGRSpatialReference*, OGRwkbGeometryType, char**) (ogrgeojsondatasource.cpp:255)
==6501==    by 0x44B772: IOWorker::exportPolygons(std::vector<std::pair<PolygonHandle*, Polygon>, std::allocator<std::pair<PolygonHandle*, Polygon> > >&, char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x477A9A: PlanarPartition::exportPolygons(char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x43A6DB: main (in /home/shared/srcs/pprepair/build/pprepair)
==6501== 
==6501== Use of uninitialised value of size 8
==6501==    at 0x609ED38: OGRSpatialReference::GetAuthorityName(char const*) const (ogrspatialreference.cpp:5919)
==6501==    by 0x5ECE987: OGRGeoJSONDataSource::ICreateLayer(char const*, OGRSpatialReference*, OGRwkbGeometryType, char**) (ogrgeojsondatasource.cpp:257)
==6501==    by 0x44B772: IOWorker::exportPolygons(std::vector<std::pair<PolygonHandle*, Polygon>, std::allocator<std::pair<PolygonHandle*, Polygon> > >&, char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x477A9A: PlanarPartition::exportPolygons(char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x43A6DB: main (in /home/shared/srcs/pprepair/build/pprepair)
==6501== 
==6501== Invalid read of size 4
==6501==    at 0x60A7A1F: OGR_SRSNode::FindChild(char const*) const (ogr_srsnode.cpp:287)
==6501==    by 0x609ED01: OGRSpatialReference::GetAuthorityName(char const*) const (ogrspatialreference.cpp:5930)
==6501==    by 0x5ECE987: OGRGeoJSONDataSource::ICreateLayer(char const*, OGRSpatialReference*, OGRwkbGeometryType, char**) (ogrgeojsondatasource.cpp:257)
==6501==    by 0x44B772: IOWorker::exportPolygons(std::vector<std::pair<PolygonHandle*, Polygon>, std::allocator<std::pair<PolygonHandle*, Polygon> > >&, char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x477A9A: PlanarPartition::exportPolygons(char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x43A6DB: main (in /home/shared/srcs/pprepair/build/pprepair)
==6501==  Address 0x1c is not stack'd, malloc'd or (recently) free'd
==6501== 
==6501== 
==6501== Process terminating with default action of signal 11 (SIGSEGV)
==6501==  Access not within mapped region at address 0x1C
==6501==    at 0x60A7A1F: OGR_SRSNode::FindChild(char const*) const (ogr_srsnode.cpp:287)
==6501==    by 0x609ED01: OGRSpatialReference::GetAuthorityName(char const*) const (ogrspatialreference.cpp:5930)
==6501==    by 0x5ECE987: OGRGeoJSONDataSource::ICreateLayer(char const*, OGRSpatialReference*, OGRwkbGeometryType, char**) (ogrgeojsondatasource.cpp:257)
==6501==    by 0x44B772: IOWorker::exportPolygons(std::vector<std::pair<PolygonHandle*, Polygon>, std::allocator<std::pair<PolygonHandle*, Polygon> > >&, char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x477A9A: PlanarPartition::exportPolygons(char const*, bool) (in /home/shared/srcs/pprepair/build/pprepair)
==6501==    by 0x43A6DB: main (in /home/shared/srcs/pprepair/build/pprepair)
==6501==  If you believe this happened as a result of a stack
==6501==  overflow in your program's main thread (unlikely but
==6501==  possible), you can try to increase the size of the
==6501==  main thread stack using the --main-stacksize= flag.
==6501==  The main thread stack size used in this run was 8388608.
==6501== 
==6501== HEAP SUMMARY:
==6501==     in use at exit: 19,782,719 bytes in 295,681 blocks
==6501==   total heap usage: 581,439 allocs, 285,758 frees, 40,621,149 bytes allocated
==6501== 
==6501== LEAK SUMMARY:
==6501==    definitely lost: 704 bytes in 26 blocks
==6501==    indirectly lost: 1,120,904 bytes in 10,886 blocks
==6501==      possibly lost: 3,532,559 bytes in 63,269 blocks
==6501==    still reachable: 15,128,552 bytes in 221,500 blocks
==6501==         suppressed: 0 bytes in 0 blocks
==6501== Rerun with --leak-check=full to see details of leaked memory
==6501== 
==6501== For counts of detected and suppressed errors, rerun with: -v
==6501== Use --track-origins=yes to see where uninitialised values come from
==6501== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

The polygons with only 3 edges are not tagged properly. Or is it on purpose? I think it is not because these polygons are not reconstructed at the end of the process.
When I add a new edge to these polygons, it is tagged properly.

After adding an edge:

For now I did this as a temporary workaround and I get the result I want but it is quite suboptimal :)

      // Transform 4 nodes polygons to 5 or more nodes polygons
      if (geometry->getExteriorRing()->getNumPoints()==4) geometry->segmentize(geometry->getExteriorRing()->get_Length()/4.0);

Regards

See http://cgal-discuss.949826.n4.nabble.com/link-static-td3455906.html

When trying to compile pprepair, I get the next message:

c++ -Wall -O3 -frounding-math -fno-strict-aliasing -I/usr/include/gdal -L/usr/lib -c PolygonHandle.cpp
In file included from PolygonHandle.h:25:0,
from PolygonHandle.cpp:22:
definitions/definitions.h:26:30: erreur fatale: gdal/ogrsf_frmts.h : Aucun fichier ou dossier de ce type
compilation terminée.
make: *** [PolygonHandle.o] Erreur 1

Which means in english: fatal error: gdal/ogrsf_frmts.h : No such file or directory of that type
compilation ended

I am under ubuntu 13.04 with GDAL 1.9.2 and CGAL 4.0.2.

Your package fails to build with CGAL 5.0. See first item under "2D Triangulations" at https://www.cgal.org/2019/10/31/cgal50-beta2/ .

Hello,
First 1000 sorry for my English and my knowledge( i am a beginner)...
I am doing this tuto : "https://www.dropbox.com/sh/tjsbi6cjb5ui95p/AADQ4pH3JQ7puDBv4sUl6zuGa/pprepair%20installation%20guide.txt?dl=0",
Everything fine but at the end i have to Open pprepair.sln in Visual Studio.
I made a C++ solution and put in all the files from "pprepair-master" (https://github.com/tudelft3d/pprepair) and all the files made with Cmake but no compilation is possible (all is in red....).
So how to do this Pprepair.sln
Thanks for all...
Jo from sunny france

Please see the attached dataset.

It appears in PlanarPartition::getBoundary()

pprepair is returning invalid polygons when we use it on the Brazilian enumeration districts shapefiles. In pacticular, some polygons returned are indeed points.

This hapens, for example, on the state of Ceara (CE, code 23, data available at ftp://geoftp.ibge.gov.br/malhas_digitais/censo_2010/setores_censitarios/ce/ce_setores_censitarios.zip ). After pprepair, the polygon cd_geocodi='230040810000012' becomes two elements of the pprepair output file: a regular corrected polygon and a point. The same also hapens with cd_geocodi='230160415000004'.

The script bellow describes steps to reproduce the errors.
After downloading the CE data, we ran prepair and pprepair :

prepair --ogr 23SEE250GC_SIR.shp --shpOut 23SEE250GC_SIR_1.shp
pprepair -i "23SEE250GC_SIR_1.shp" -r fix -o 

Then we imported the output shapefile into PostGis and ran some tests (we tryed runing test directly using prepair on the shapefile outputed by pprepair. However it did not work becuase multipolygons get divided into different lines, making prepair err).

shp2pgsql -s 4674:4326 -I -W LATIN1 -g geom 23SEE250GC_SIR_1.r  SC_table | psql -h server -d database 

At first, all elments of the shapefile are "multipolygons" but PostGis indicates this is an invalid shapefile.

select count(*), GeometryType(geom) from SC_table group by GeometryType(geom) 
# all are multiplolygons
select count(*), IsValid(geom) from SC_table group by IsValid(geom)
# we find 248 invialid polygons

We then run ST_makeValid() on the polygons and count the frequencies of greometry types again:

select count(*), GeometryType(ST_MakeValid(geom)) from SC_table
group by GeometryType(ST_MakeValid(geom))
# we now have MULTIPOINT ou um MULTILINESTRING elements

Above, ST_makeValid() coerces some elements to points and lines. For example:

select * from SC_table where (cd_geocodi='230040810000012' or cd_geocodi='230160415000004') 

We are using a Linux machine, prepair-improvements-with-ogr and pprepair-new

As reported in Debian Bug #802495, pprepair fails to build with GDAL 2.0:

  error: 'Open' is not a member of 'OGRSFDriverRegistrar'
  error: 'class GDALDriver' has no member named 'GetName'
  error: invalid conversion from 'GDALDriver*' to 'OGRSFDriver*'

The full build log is attached to the bugreport, which GitHub didn't allow me to do here:
pprepair_0.0~20150323-6284890-2_gdal-2.0.log

pprepair needs to be patched to support GDAL 2.0,
please refer to the MIGRATION GUIDE FROM GDAL 1.11 to GDAL 2.0 for pointers.

As I reported in another issue, the output of pprepair seems to contain some invalid polygons and some minor overlaps (at least that is what we detect when imported into Postgis). So I tried running pprepair on its own output. And also prepair > pprepair on the output of the original prepair. It does not work (see bellow).

-- 0) Starting at a folder with the shapefiles repaired by pprepair-new
-- 1) Run pprepair-new on the original repaired files (item 0)

mkdir pprepair
for f in *.shp;
do pprepair-new -i $f  -o ./pprepair/ -r fix;   
done
-- this returns several kinds of errors, and does nor run for any of the shapefiles. Errors are:
Invalid polygon: duplicate vertices. --> Polygon #260  ** (most commeon error)**
Warning 1: Self-intersection at or near point ...
Warning 1: Ring Self-intersection at or near point ...
Warning 1: Too few points in geometry component at or near point ...
ERROR: Some polygons are (individually) invalid. (our other project 'prepair' can perform automatic repair of single polygons)
Aborted.
...

-- 2) Following advice on ther error message in item 1, run prepair on the original pprepair files (item 0)

mkdir prepair
for f in *.shp;
do prepair-improvements-with-ogr --ogr $f  --shpOut ./prepair/pr_$f;
done
-- This runs for all files, although giving these errors:
Creating ./prepair/pr_pr_11SEE250GC_SIR.r.shp...
You are using an exact number types using a Constrained_triangulation_plus_2 class would avoid cascading intersection computation and be much more efficient

-- 3) Finaly I run pprepair on the files generated in step 2).

cd ./prepair
mkdir pprepair

for f in *.shp;
do pprepair-new -i $f  -o ./pprepair/ -r fix;  
done
-- This returns the following error message for every file
Reading input dataset: pr_pr_11SEE250GC_SIR.r.shp
    Reading layer #1 (2453 polygons)
    Validating individually every polygon...
Warning 1: Self-intersection at or near point -60.813078443236904 -12.819574178491102
--> Polygon #1005

ERROR: Some polygons are (individually) invalid. (our other project 'prepair' can perform automatic repair of single polygons)
Aborted.

-- 4) Since the none of the above worked, we tried importing the the original pprepair files (item 0) into Postgis. There we: made polygons valid (ST_MakeValid), selected only the parts that were actually polygons (as opposed to lines and points), and regrouped the areas that used to belong to a multipolygon and had been slipt into single polygons by pprepair. We finally exported the files back to shapefiles and run setps 1), 2) and 3) on these exported files. We got the same errors as above

PS: the good news is that we finally managed to run pprepair-new in Linux. Due to our limited git-knowledge we were compiling pprepair-master instead of pprepair-new...

Cloning from github gives me definitions/definitions.h, but PolygonHandle.h includes definitions/Definitions.h so it fails on a case-sensitive OS (linux).

When attempting to repair self-intersections, the number of features increases by more than 5x.
I am using the following command:
./pprepair -i clip.geojson -o clip_out -rtnn

I'm attaching both the original clip.geojson and the repaired clip_repaired.geojson in the following gist. The former has 3 features in total while the repaired file has 22 features. Would it be possible to keep the number of features closer to the original?

https://gist.github.com/monica2587/ede9efe11ee37965811b

As discussion in issue #36 indicates, the -r LB (longest border) criteria will handle ties by assining the problematic area to a RN (random neighbor). However this random choice occurs among all neighbors, including the ones that have the smaller borders.

In case of ties in "r -LB" criteria, -RN should choose only among the neighbors that have the longest border.

(and please make sure this change trickes down to pprepair-new, or any version that runs on linux)

Hi, this looks like a very promising approach that I hope to use for cleaning up user generated polygons. I have tested it now with some of my data, and I get a segmentation fault.

$ wget https://dl.dropbox.com/u/31890709/Poly_test.zip
$ unzip Poly_test.zip

$ pprepair -i Polygon_tester.shp -o Poly_fix.shp -fix
[snip]
Repair successful (0 s). All polygons are now valid.
Triangulation already repaired!
Repaired triangulation:
Holes: 0 triangles (0.00000000 %)
Ok: 739 triangles (100.00000000 %)
Overlaps: 0 triangles (0.00000000 %)
Reconstructing polygons (geometry)...
Polygons reconstructed (0 s).
Exporting polygons...
Writing file...
Segmentation fault

Do I have to use some of the other options first on this dataset to fix it, or is there something else going on here? Will appreciate any insight on this you can provide.

Many thanks for making this available!

summary

Several errors when running make, like this:

pprepair/IOWorker.cpp:1242:20: error: 'path' is not a member of 'std::filesystem'
 1242 |   std::filesystem::path extension = std::filesystem::path(file).extension();
      |                    ^~~~

fix available

#57

We noticed that the pprepair output file with the triangulation contains invalid polygons. Upon inspection, the triangulation contains some elements that are actually points or lines. You can reproduce this error with any of the Brasil, Enumeration District files.

We ran:
pprepair -i file.shp -v --outtr triang.shp
(pprepair-new version, from maybe a week ago)

Then imported triang.shp in Postgis, and tested the Validity of the polygons ( ST_IsValid). A small fraction of the polygons are invalid. After fixing them in POSTGIS (ST_MakeValid) the invalid polygons all became either points or lines (I'll post a follow up comment with frequency of such problems).

Visual inspection seemed to indicate that these invalid polygons were "redundant" (i.e. for every point/line (invalid polygon) there were two valid triangles for which borders coincide with the point/line. So I just deleted the invalid polygons. However, after deleting the triangulation is no longer is a planar partition. I tried running ST_Union on the "cleaned" triangulation and got "non noded intersection" error messages.

PS: we finally gave up installing pprepair on Linux and installed it on a MAC-OS (in fact VirtualBox inside another machine). So now we think we have an environment similar to what the developers use.

Hi,
I had an issue when trying to read some shapefiles in which some features have no geometry (feature->GetGeometryRef() returns 0). It raised a segfault in this case.
I can't make a pull request but just adding this to line 160 solves this issue:
if (!feature->GetGeometryRef()) continue;
Regards

The output shapefile does not have a .prj file.

We need to check that holes are fully inside their polygons.

Why? In order to support snapping to an extent, we need to also tag from holes in the direction of their corresponding outer boundary, but this only works if we ensure that all holes are properly nested.

Hi,

Let me begin by saying that if I can make this program work, it'll solve a big problem that I have with several cadastral data sets. I'm really looking forward to having polygons with consistent topology!

Unfortunately, it appears to be failing on the very first data set that I've tried. I'm attaching the shapefile that I'm trying to process:
bws_for_pprepair.tar.gz

I'm trying to run what I understand is the simple, stupid way of making them valid:

/storage/kennykb/Distributions/pprepair/build/pprepair -bd -i bws_for_pprepair/sql_statement.shp -o bws_pprepaired/pprepaired.shp -fix

and what I see is shown below. After those lines are output, I wait a couple of hours, and nothing happens.

I realize that some of the polygons are digitized to an inappropriate level of precision. I'm trying to find a way to repair the topology and simplify them, and was hoping that pprepair was that way.

I suspect that I'm abusing it, or misunderstanding what it does. Can you perhaps advise me on what I'm doing wrong?

Adding a new set of polygons to the triangulation...
    Path: bws_for_pprepair/sql_statement.shp
    Type: ESRI Shapefile
    Layers: 1
    Reading layer #1 (363 polygons)...
>       string      name
        string      NYCDEP_tow
        string      NYSDEC_wil
        string      NYCDEP_las
        string      foot
        string      fishing
        string      hunting
        string      trapping
        string      website_ma
        string      website
        string      leisure
        string      boundary
        string      protection
        string      protecti_1
        string      protecti_2
        string      related_la
        string      operator
        string      governance
        string      site_owner
Polygons added (2 s). The triangulation has now:
    Vertices: 123689
    Edges: 371064
    Triangles: 247350
Tagging...
Tagging done (0 s).
Input triangulation:
    Holes:    2553 triangles (1.032141 %)
    Ok:       244241 triangles (98.743077 %)
    Overlaps: 556 triangles (0.224783 %)
Repairing regions by longest boundary...
Repair of all polygons not possible (0 s).
Repairing regions by random neighbour...

Hello, we have encountered a problem with this geometry. It has 6 polygons, with 1 and 2 duplicated. When we run

./pprepair -i polys.shp -o polys_fix.shp -fix

pprepair hangs and has to be aborted. Some testing reveals that the problem lies with option -rrrn. Every other option results in a solution, albeit one that kills polygons 4 and 5 (which seem valid, shown here in red).

We have built pprepair to output to .shp (because of an existing workflow) rather than geojson, and are using it with gdal 2.2.3.

Any thoughts on why this is hanging? Thanks

Hello,

We have been using pprepair quite successfully recently to clean up many hand digitized polygons. However, we got this error on one recently.

$ wget(https://dl.dropboxusercontent.com/u/31890709/mt_21FDWIOV1S7STSB8SJS3.zip)
$unzip(mt_21FDWIOV1S7STSB8SJS3.zip)

$ pprepair -i "mt_21FDWIOV1S7STSB8SJS3.shp" -o "mt_21FDWIOV1S7STSB8SJS3_fix.shp" -fix

Adding a new set of polygons to the triangulation...
Path: mt_21FDWIOV1S7STSB8SJS3.shp
Type: ESRI Shapefile
Layers: 1
Reading layer #1 (11 polygons)...

  int         gid
    string      name
    string      completion
    string      assignment
Feature #2 (6 vertices): self intersecting outer boundary #0. Split.
Created 1 rings.
Feature #10 (16 vertices): self intersecting outer boundary #0. Split.

terminate called after throwing an instance of 'CGAL::Precondition_exception'
what(): CGAL ERROR: precondition violation!
Expr: hierarchy.is_constrained_edge(va,vb)
File: /usr/include/CGAL/Constrained_triangulation_plus_2.h
Line: 233
Abort (core dumped)

Thanks in advance for your thoughts on this!

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

I found a case where pprepair introduces two duplicate vertices in one polygon at the junction of three polygons.
Example: the yellow polygon initially has no vertices at the junction, but after running pprepair (the new branch) with -r fix it has two vertices at the junction with the same coordinates. See screenshot.

gpkg file with the 3 polygons

It would be extremely usefull if pprepair provided the information linking each triangue in the triangulation to the original poligons in the input file that it overlaps (is contained in).

This could be done as an additional character column in the dbf file containing an array of ids from the original shapefile (as in the example table bellow)

Why? Because it would make it much easier to understand what changed, create statistics on the percentage of polygons (or polygon borders) that changed. Knowing that 3% of the triangulation polygons had problens is much less usefull than knowing that x% of the original polygons had problems. Also if makes if easyer to inspect visually the changes made.

To test pprepair, I use an other dataset with 117710 polygons.
After a few features, th program stays on feature #21929, and the free memory decrease from 5.4G to zero and the program abort.

What I do:
curl -o /tmp/RPG_2010_35.ZIP http://www.data.gouv.fr/var/download/ign/RPG_2010_035.ZIP
( cd /tmp ; unzip RPG_2010_35.ZIP)
pprepair -i /tmp/RPG_2010_035.shp -o /tmp/fix.shp -fix

This is only a test, I don't need a fix for this dataset.

Hi! We have built pprepair into software that for various reasons has to use an older version of gdal (1.9.2). The reason is this:

OGRFeature::GetGeometryRef()

Which is in gdal 1.11 but not 1.9.2.

Is there an earlier version that does not have this dependency, but which is sufficiently robust to incorporate into a production environment?

Thanks!