pprepair fails with terminate called after throwing an instance of 'CGAL::Assertion_exception' about pprepair HOT 5 CLOSED

It works for me...

Adding a new set of polygons to the triangulation...
Path: /Users/ken/Desktop/parcelles/FSAC_parcelles.shp
Type: ESRI Shapefile
Layers: 1
Reading layer #1 (29 polygons)...

  string      Colonne1

Polygons added (0 s). The triangulation has now:
Vertices: 132
Edges: 393
Triangles: 254
Tagging...
Tagging done (0 s).
Input triangulation:
Holes: 0 triangles (0.00000000 %)
Ok: 254 triangles (100.00000000 %)
Overlaps: 0 triangles (0.00000000 %)
Repairing regions by longest boundary...
Repair successful (0 s). All polygons are now valid.
Triangulation already repaired!
Repaired triangulation:
Holes: 0 triangles (0.00000000 %)
Ok: 254 triangles (100.00000000 %)
Overlaps: 0 triangles (0.00000000 %)
Reconstructing polygons (geometry)...
Polygons reconstructed (0 s).
Exporting polygons...
Overwriting file...
Writing file...
Polygons exported (0 s).
Done! Process finished in 0 minutes 0 seconds.

from pprepair.

Are you sure we're using the same shapefile? I don't even get any errors in it...

Also, I get 29 polygons instead of 25

from pprepair.

Thank for your fast response
What I do:
for ext in shp shx prj dbf ; do
curl -o /tmp/FSAC_parcelles.${ext} http://mga.alwaysdata.net/geo/GDB/FSAC_parcelles/FSAC_parcelles.${ext}
done
md5sum /tmp/FSAC_parcelles.*
./pprepair -i /tmp/FSAC_parcelles.shp -o fixed.shp -fix
The md5 of the files:
407ff92b2718e6f2828052accebdb6e3 /tmp/FSAC_parcelles.dbf
37fdc6bb4d46b104c618c8f8634975ad /tmp/FSAC_parcelles.prj
d7ac8220f264ea13352923ffb9a8955d /tmp/FSAC_parcelles.shp
04a01350de5bfeae654ac2d161015cac /tmp/FSAC_parcelles.shx
I am on a debian squeeze:
Linux debian 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux

from pprepair.

Ok, I can reproduce the error now.
Short story: Uncomment the line #define EXACT_CONSTRUCTIONS in definitions/CGALDefinitions.h and it will work
Longer story: Processing some data sets require a higher level of precision than the default option (floating point) can provide. We don't enable this option by default because it comes with some disadvantages too. It uses far more memory (4x is common), processing takes a bit longer, and output has to be in floating point anyway, so sometimes the data is valid in memory but invalid in the output.

from pprepair.

With this configuration, it's good for me too.
Tanks a lot !

from pprepair.