Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pprepair hangs #42

Closed
kennykb opened this issue Jun 2, 2016 · 3 comments
Closed

pprepair hangs #42

kennykb opened this issue Jun 2, 2016 · 3 comments

Comments

@kennykb
Copy link

kennykb commented Jun 2, 2016

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
Copy link
Author

kennykb commented Jun 2, 2016

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
Copy link
Author

kennykb commented Jun 3, 2016

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants