tudelft3d / pprepair

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

pprepair hangs #42

Closed kennykb closed 8 years ago

kennykb commented 8 years ago

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...
kennykb commented 8 years ago

Oh, I should have mentioned, version was the 'master' branch, downloaded and compiled yesterday. GDAL and CGAL are both whatever is current on Ubuntu Xenial, I can retrieve that information if it makes a difference.

kennykb commented 8 years ago

After reading the conversations on several other issues here, I tried building from the 'new' branch.

Initially, it seems much better. The program runs impressively fast, and the irregular boundaries between the polygons are dissolved quite as I expected.

The one thing that becomes a surprise is that holes in the polygons are now filled. In the data set that I uploaded earlier, for instance, the polygon with ogc_fid=338 name='Sand Hill Unit' has had the two large enclaves on its southwestern border filled in.

I think I can work around this by adding extra polygons in upstream processing so that the holes will be occupied, and only then using pprepair to dissolve borders.

Is the filling of holes expected and unavoidable, or am I missing something?

hugoledoux commented 8 years ago

yes, indeed branch "new" is better sometimes, we might merge it with master soon, if we get back to working on this.

Holes will be filled, because that's the whole point of pprepair: to create a PP from a set of input. The branch "new" doesn't have yet a way to tell it that certain polygons shouldn't be filled (the master branch let,s you define a point); we might add that in the future. In the meantime, I suggest you use your hack. But