Opened 13 years ago
Last modified 12 years ago
#1806 closed defect
Extremely slow and CPU-intensive ST_MakeValid (ST_BuildArea) case — at Version 7
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | high | Milestone: | PostGIS 2.0.1 |
Component: | postgis | Version: | 2.0.x |
Keywords: | Cc: |
Description (last modified by )
The attached shapefile contains a single geometry. A multipolygon composed by a single polygon containing 4213 rings with a total of 82304 vertices.
Passing it as an argument to ST_MakeValid takes forever.
Change History (8)
comment:1 by , 13 years ago
comment:3 by , 13 years ago
Summary: | Extremely slow and CPU-intensive ST_MakeValid case → Extremely slow and CPU-intensive ST_MakeValid (ST_BuildArea) case |
---|
Yep, confirmed you can hook things forever by calling ST_BuildArea(ST_Boundary(geom))
comment:4 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Also memory usage keeps increasing.
Plan: rewrite BuildArea to avoid all those SymDifference calls and simply skip polygons fully contained in other polygons (assuming those ones are holes of the other). Should work pretty good and fast...
comment:5 by , 13 years ago
polygonize finds 3536 polygons, so ST_BuildArea is stuck computing the symdifference between each of them and the aggregated result. While it goes on the time it takes to compute the symdifference grows. It starts with roughly 20 items per second. At iteration 1700 computes ~5 symdifference per second... Every iteration has to rebuild the topology which was already built in the previous iteration.
comment:6 by , 13 years ago
Step back: I was completely wrong about how the geometry was rendered. At least, I can't handle to render it that way again. The information about composition is correct.
comment:7 by , 13 years ago
Description: | modified (diff) |
---|
How does it look in qgis: